A recent exercise at the job around improving the accuracy of estimate for software delivery projects caused me to have a minor epiphany!
When doing agile software delivery, we generally get value from having more information sooner. But this plays differently in managing the backlog.
We have been working on writing basic stories for all the ideas in our backlog, and producing T-Shirt size + Confidence estimates on each story. The challenge, is to scope a release and commit to a schedule with greater precision. Our customer (and management) would like us to estimate with greater precision, to match the estimates that are performed at each stage-gate in our non-agile software delivery life cycle.
The problem is, that our backlog (“Chinese menu”) estimates do not contemplate the state of the code base at the beginning of the release. We do this intentionally, so that the customer (product owner) can move stories backward and forward in the sequence without considering any cost or schedule optimization that could be had if we delivered in some sequence other than VALUE OPTIMAL.
We all, when making estimates, start with the CURRENT state of the code base as an assumption. So if estimates are not adjusted for backlog items for a couple of iterations they get old. Sometimes development makes it easier to accomplish a specific task, and sometimes it makes it harder. This is hard to predict – you simply don’t know when you will introduce some code edifice for a feature that will need to be re-worked to build some subsequent feature.
So in our SDLC estimation methodology, we have 3 gates – 1) After Scope, 2) After Requirements, 3) After Design – and we also have the Zero gate estimate which is based on a napkin. You know two executives sat in a bar and doodled on a cocktail napkin and the next Monday, you were asked for an estimate.
So if you think of it, in the gated life cycle, the information available at each gate is as follows:
Gate Zero – an idea, the current state of the code base.
Gate 1 – a group of ideas to be delivered together, the current state of the code base.
Gate 2 – a group of ideas, with a detailed understanding of implementation constraints, and the current state of the code base.
Gate 3 – a group of ideas, the detailed understanding of implementation constraints, with an understanding of implementation strategy, and the current state of the code base.
The truth is that all of our backlog estimates are somewhere in between Zero and 2 gate. We have requirements that are somewhat more detailed than a napkin, but no release scope. We have a detailed understanding of the CURRENT code base, but we recognize that we will NOT be delivering against that code base, but some future version of that code base. In some cases, we may have an understanding of implementation strategy – but we allow implementation strategy to emerge so we hold it loosely.
Because we recognize that we are estimating without a committed release scope (or delivery sequence) we tend to include all dependencies in our estimates. Let me say that differently, if two features require some common work, and we don’t know which one will be delivered first, we tend to include the common work in both estimates. This is a direct result of not knowing the future state of the code base at the point of release scope commitment.
We also recognize that any features that are delivered between now and the time we start any future release will ADD INFORMATION about our customers desire for features that are in the backlog. We hold in our our belief system that responding to this information INCREASES the VALUE of whatever we deliver later, because we simply know more about our customers desires and needs.
My epiphany was simply this – in agile projects, we ACKNOWLEDGE that our estimates have lower fidelity because we understand that we are not optimizing the delivery sequence against cost and schedule constraints – but to deliver the most value as early as possible. We hold in our belief system that creating higher fidelity estimates is less important than optimizing the value delivery sequence.
In agile delivery methods, the customer participation is important because they get to control the sequence of delivery of value to the user community. They do this by sequencing the backlog. The traditional project management philosophy employed by phase gated software delivery life cycle devotees tends to optimize the delivery sequence to optimize the value to cost, but by optimizing value to cost within a release, you can get most of the way through a release cycle without completing a single feature. In doing this you have sunk half the cost of the release before you deliver ANY value.
One of the problems we have selling agile in the context of the enterprise is that agilists often forget about the business drivers for project estimation. While I am convinced that agile practices get me to a higher quality, higher value software product, and a more predictable, more controlled delivery process, explaining this to people who have no experience observing how it happens is a challenge. Estimation is about predictability, and specifically about giving people the ability to decide how they want to spend their money. Those of us selling agile in the enterprise have to realize why our customer and our management LIKE estimates, how they USE estimates, and how they PERCEIVE estimates. So many of us in the agile space like to think of estimates as a complete waste of time, and purely from the perspective of software delivery it is – estimating how much work is require to get to done is not as important on defining the steps required to get to done. From the perspective of the product owner, however, the cost to value ratio of any capability is an important piece of information and the cost is only available in the form of an… Estimate.
My next post will be about how Agile solves the problem of estimation fidelity – differently than phase gated life cycles, and how you can get your sponsors, executives, and stakeholders to relax and feel comfortable with that solution.
No Comments