Time boxing is a management technique which prioritizes schedule over deliverables. This means that if during the execution of the task it is anticipated that all requested deliverables will not be ready by a set completion date, the scope of the work will be reduced so that a smaller, yet still useful, output is produced by such date. The two dimensions of the time box are the length of time it is given and the resources available during that time. The time box concept can be applied to individual tasks and single iterations but the focus of this proposal is in larger aggregates, such as a release or a project, culminating in the delivery of an agreed functionality to a customer.
To be effective, time boxing requires that (Miranda, 2002):
- The features or user requirements1 that make up the total delivery are grouped into functionally complete subsets;
- The subsets are prioritized so it is clear which requirements should be implemented first and which ones could be eliminated if there is not enough time to complete all of them; and
- Reasonable assurance is provided to the customer about the feasibility of a given subset within the imposed frame
Time boxes which are merely a self, or an outside, imposed target without agreed partial outcomes and justified certainty are at best, an expression of good will on the part of the team.
Prioritization is traditionally made by asking the customer to rank his or her preferences into a series of categories such as "Must have", "Should have", "Could have" or "Won't have" where the "Must have" category contains all requirements that must be satisfied in the final delivery for the solution to be considered a success. The "Should have" represents high‐priority items that should be included in the solution if possible. The "Could have" corresponds to those requirement which are considered desirable but not necessary. They will be included if there is any time left after developing the previous two. "Won't have" are used to designate requirements that will not be implemented in a given time box, but may be considered for the future. These categories are commonly known by the acronym "Moscow" (Stapleton, 2003). Less used techniques include the pairwise comparisons, cumulative voting, top ten requirements and EVOLVE (Berander & Andrews, 2005).
With the exception of EVOLVE (Greer & Ruhe, 2004) which uses a complex search procedure to maximize value within the constraints imposed by the available resources; all the techniques above suffer from the same problem: they are either unconstrained or arbitrarily constrained. For example in the "top ten" technique the "must have" would be limited to the 10 more important requirements. Why 10? Why not eleven or twelve or nine? This lack of constraints means that in general, as long as the aggregated effort is within the project budget there is no limit to the number of requirements that are assigned to the "must have" category with which the prioritization process ends up not prioritizing anything at all.
In this article we describe a simple requirement prioritization method that: 1) Redefines the MOSCOW categories in terms of the team's ability to complete the requirements assigned to them; and 2) Constrains the number of requirements that the customer can allocate to each category as a function of the uncertainty of the estimates which makes it possible to give the sponsor certain reassurances with regards to their achievability or not. The MOSCOW categories are redefined as follows:
- Must Have: Those features that the project, short of a calamity, would be able to deliver within the defined time box
- Should Have: Those features that have a fair chance of being delivered within the defined time box
- Could Have: Those features that the project could deliver within the defined time box if everything went extraordinarily well, i.e. if there were no hiccups in the development of requirements assigned to higher priority categories
- Won't have features, those for which there is not enough budget to develop them
Therefore, the fitting of requirements into these categories is not an a priori decision but rather a consequence of what the development team believes can be accomplished under the specific project context and budget.