Agile development has always included the practice of timeboxing–setting a fixed project time limit. However, timeboxing can also be used in another interesting way–timeboxing capabilities and stories rather than estimating them.
Working with a client that was in an early stage of development of a medium sized (over 75 people on the project), lengthy (over 2 years) project we used the idea of timeboxing capabilities during release planning. Some of the capabilities in the backlog were reasonably well defined and others were ambiguous. There were in fact a significant number of capabilities for which the potential scope was wide and estimates ranged from x to 10x or more. Furthermore, some of these capabilities were tentatively scheduled late in the project. Rather than spend significant time defining requirements and estimating capabilities that were subject to change anyway, we approached sizing by constraining (timeboxing) rather than estimating.
Timeboxing approaches the problem of sizing by looking at business value rather than requirements. The question becomes “how many story points (or effort) do you think we can spend on this capability given its value relative to other capabilities?” On one capability whose range of possibilities from the development team’s experience was somewhere between 40 and 1,000 story points, it was actually fairly easy for the product owner to say, “I think we should timebox this capability to 60 story points.” The 1,000 story points was way out of line with the relative value of this capability. The “constraint” of 60 story points seemed a reasonable cost given the overall product objectives.
Remember, this was a release planning exercise for a large project with a 2 year overall effort (it was more of a road mapping effort) and the objective of the planning session was to establish the feasibility of the project and lay out an early plan. Timeboxing size rather than estimating size was much faster that trying to discuss and estimate scope.
Early sizing in project release planning is inexact no matter which method is used. Attempts at defining scope and estimating often end up wrong as projects unfold and teams learn more about the requirements. Similarly, sizing by constraining can give a false sense of correctness, particularly if little thought is given to the “reasonability” of whether adequate functionality can be delivered within the capability timebox. Scoping and estimating is preferred for some capabilities, while timeboxing should be preferred for others. They can even be used together, timeboxing to get into a ballpark, then scoping and estimating within that ballpark.
Timeboxing size rather than estimating size can be another useful technique in the agile project manager’s toolbox.