In an excellent article from Mike Cohn, where he talks about budgeting when you can’t estimate, he touches on an important but often overlooked Agile practice, time-boxing:
Instead of asking a team, “How long will this take?” the business thinks, “How much time is this worth?” In effect, what this does is create a budget for the feature, rather than an estimate. Creating a budget for a feature is essentially applying the agile practice of timeboxing. The business says, “This feature is worth four iterations to us.” In a healthy, mature agile organization, the team should be given a chance to say if they think they can do a reasonable job in that amount of time. If the team does not think it can build something the business will value in the budgeted amount of time, a discussion should ensue. What if the budget were expanded by another sprint or two? Can portions of the feature be considered optional so that the mandatory features are delivered within the budget? Establishing a budget frames this type of discussion.
I’m sure there will be distant shouts of “it’s done when it’s done”, but I regard that as a negative attitude and somewhat unrealistic. Everything we produce (in a commercial context) is paid for by the business, so ultimately they should be in control of how much they spend. Whilst time-boxing doesn’t guarantee they’ll get (everything) that they want, it should ensure costs don’t spiral.
There are three critical aspects to successful time-boxing, collaboration, ante and negotiation (think CAN you time-box).
Collaboration
In order to have the best possible chance of realising the value the business hopes to achieve within the time-box, the whole team will need a clear understanding of what the ideal outcome would be. Focus should be on what is really needed and how to prioritise to get there.
Negotiation
If there is enough uncertainty or too many unknowns, it’s crucial that the requirement is negotiable. As the article mentions, can portions of the feature be considered optional? The aim should be to negotiate a modular / gradual outcome where at least the lower spectrum of value can be delivered within the constraints with relative confidence.
This is very much an application of the INVEST characteristics defined by Bill Wake:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
This principle is usually applied to user stories, which is what the portions of the feature provoking the time-box should be broken down into.
Ante
The ante is the size of the time-box, the monetary stake in the game. If the uncertainty is very high, the business has to accept the risk that the stake’s value may not be returned.
Occasionally, due to the size or complexity of a feature (or possibly external factors), it may become clear that the feature MVP cannot be delivered within the time box. If it’s likely to be significantly incomplete, this should become clear relatively early on. If you’re 2 Sprints into a 4 Sprint time-box and have only completed 10% of the effort for the minimum viable elements of the feature, there’s a strong chance the remaining 90% will not be completed in the remaining time.
With the above example in mind, you have three choices:
- Fold – you’ve reached a point within the time-box where it looks like you’re not going to get a return so you fold early, ending the time-box.
- Call – you hold your nerve until the end of the time-box. It’s still possible that you’ll get the output / value you want. As we all know, burn-down is non linear.
- Raise – at the end of the time-box, the team may have delivered most of the portions of the feature, but you may now feel it’s worth a small extension (based on the team’s velocity) to add more value.
In theory, you could also raise the ante if the team didn’t deliver the minimum viable feature negotiated at the start. I’d usually recommend against this as it’s difficult to assess progress if you don’t have “working” software to base your projections against. Your budget (in terms of money or time) was negotiated early on – spending more than the feature adds is precisely what this approach should avoid.
Setchu - Agile at Scale 