Creating a long-term product-roadmap or release plan for a large project is a challenge. Features that are going to be implemented in many months ahead aren’t probably well-defined and, therefore, it’s very difficult to size and estimate them reasonably. Moreover, if you’re laying out an early version of the plan it doesn’t make any sense to invest significant time to scope and size those features because they are going to change anyway.
To cut this Gordian knot, you can approach sizing by constraining (time-boxing) rather than estimating.
The idea is to look at business value rather than details of requirements. The team, instead of sizing a feature in points, agrees with the Product Owner the amount of time (i.e. 50 days) he’s willing to invest in the feature bearing in mind its relative business value. This approach enables the team to reduce project’s uncertainty quickly and complete initial planning session at reasonable time and cost.
Of course, the ballpark provided as a result of time-boxed sizing is not set in stone and has to be revised on a regular basis (as each and every estimate, though). The more the team knows about the feature the easier it’s to split it into smaller chunks and finally estimate it in points.
It’s worth mentioning that time-boxed sizing doesn’t guarantee that the ballpark provided is correct and absolutely feasible. On the other hand, it’s not to say that time-boxed sizing is about guesstimating – the value should be reasonable. But for early planning exercises, it gives a common understanding of the size of the feature and brings stakeholders’ expectations into line. Adaptability and change lie in the heart of agility so it’s not a surprise that after several grooming sessions the ballpark size may change.
Time-boxed sizing was suggested by Jim Highsmith in Agile Project Management for large and lengthy projects. I think that it may be also useful in smaller projects when product management team is thinking about a new feature but doesn’t know how exactly it should work. Establishing a time-boxed size for such a feature sets clear boundaries and constraints for future discussions and makes the team plan within the ballpark. It’s not to say that the size of the feature can’t finally exceed an initial value – it’s Product Owner’s call after fall. But it forces the team to make decisions relatively quickly and allows them to focus on agreed ballparks.
