Agile Project Management: Creating Innovative Products (Agile Software Development Series) by Jim Highsmith

Author:Jim Highsmith [Highsmith, Jim]
Language: eng
Format: epub
Published: 0101-01-01T00:00:00+00:00

Timeboxed Sizing

Agile development has always included the practice of timeboxing—setting a fixed time limit to overall development efforts and letting other characteristics such as scope vary. However, timeboxing can also be used in another interesting way: timeboxing capabilities and features.

Working with a client that was in an early stage of development of a large (over 40 people), lengthy (over 2 years) project, we used the idea of timeboxing capabilities during release planning. We were planning at the capability level, but some of the capabilities were reasonably well defined and others were still ambiguous. There were, in fact, a significant number of capabilities for which the potential scope was wide (in one case estimates ranged from 50–600 days of work). Furthermore, some of these capabilities were tentatively scheduled late in the project. Rather than spend significant time scoping and estimating capabilities that were subject to change anyway, we approached sizing by constraining (timeboxing) rather than estimating.

Constraining approaches the problem of sizing by looking at business value rather than requirements. The question becomes, "How many hours or story points do you think we can spend on this capability given its value relative to other capabilities?" On the capability whose range of possibilities was between 50 and 600 days, it was actually fairly easy for the product manager to say, "I think we should timebox this capability to 75 days." The 600 day estimate was way out of line with the relative value of this capability. The "timeboxed size" of 75 days seemed a reasonable cost given the overall product objectives.

Remember, this was a release planning exercise (that was actually more of a road map with additional estimating) for a large project with a two-year overall effort, and the objective of the planning session was to establish the feasibility of the project and lay out a early plan. Constraining size rather than estimating size was much faster than trying to discuss and agree on the scope. Constraining capabilities allowed the team to rapidly reduce the project's uncertainty. It also let the team, product, and executive management understand that for the project objectives to be met, certain capabilities would have to be bounded.

In many projects, the fuzziness of scope allows two groups to have very different expectations about what will be delivered. One group, usually product management, envisions a gold-plated capability while the development team envisions a bare-bones one. Timeboxed sizing can help bring these expectations into line early in the project. It is easy to misinterpret a scope description to meet one's own expectations (no matter how much time is spent defining that scope). It is harder to misinterpret a sizing number—75 days.

Early sizing in project release planning is inexact regardless of method 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.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.