When organizing a sprint, there are two ways to ‘scope’ the work for each Sprint: Time-boxed or Feature-boxed.
In a ‘feature-boxed’ approach, a set of features, defects and chores are defined to ‘scope’ the work to be done during the Sprint. Once those features are complete, the Sprint is complete. There are several advantages to this approach.
The first advantage is that you know exactly what features will be completed during the Sprint. There’s no question which features will be completed, because by definition a specific collection of features define the Sprint’s scope.
A second advantage is that you don’t have to worry as much about which order you work on the features (or defects/chores) in the Sprint. Since you’ll get to them all anyway, you can order the work in whichever way you want.
But in that second advantage lies a significant disadvantage: Because you don’t have to worry about which order the features are completed, you’re not forced to prioritize as aggressively. If time runs out near the end of the Sprint you may end up abandoning features in order to bring the Sprint to a close. Moreover, it’s possible that some of the features completed early in the Sprint may not have been the most critical pieces of work.
Contrast this with a ‘time-boxed’ Sprint approach. In the ‘time-box’ approach, the end calendar date for the Sprint is determined at the outset. The Sprint is complete once that day is met and all work that’s going to be launched needs to be done, through QA and ready for launch.
Time-boxing the Sprint requires a much sharper focus on prioritizing work, since you can’t push the end date if work isn’t done. Features that aren’t complete get pushed to the next Sprint.
This forces decisions much earlier on what will and what won’t make it into the Sprint. In fact, hard decisions on prioritizing work should really be done right at the outset. Decisions on what features get pushed to the next Sprint have to happen very early — otherwise testing can’t be completed before the end of the Sprint.
One technique I’ve used to prioritize features is to use what’s referred to as the MSCW (or ‘Moscow’) rating. MSCW is an acronym for:
- ‘M’ – Must – The feature MUST get done during the Sprint
- ‘S’ – Should – The feature SHOULD get done during the Sprint
- ‘C’ – Could – The feature COULD get done during the Sprint
- ‘W’ – Won’t – The feature WON’T get done during the Sprint
By tagging each feature with a MSCW rating at the outset, decisions on which features will and won’t make it into the Sprint is built into the process from the beginning. This approach enforces a discipline that ensures features are prioritized correctly.