MoSCoW prioritisation for Timeboxes in Agile projects
Image reference
Projects have to balance the Time, Cost, Quality and Features delivered, somewhere there has to be a variable. In a traditional project, the cost and time is the variable. Therefore, the project will likely be over time and over budget as all features have to be developed, leading to inconsistent quality. In contrast, an Agile project keeps the time, cost and quality fixed while having the features variable. This leads to high-quality features delivered in time and to budget, but not all features will be developed. To achieve this, the requirements for the project are prioritised into the categories of; Must have, Should have, Could have, Won’t this time. As a general rule, the Must have requirements shouldn’t take over 60% of the available time and effort in a project or timebox.
Must have
The Must have requirements make up the Minimum Viable Product (or Minimum Usable Subset) for agile projects and should take up no more than 60% of the projects time and effort. They are the parts of the project that have to be delivered for the system to be usable, such as;- To ensure that it meets the legal requirements
- The system would not be functional without it
- Unsafe without it
- Cannot deliver a viable solution without it
Should have
Should have requirements ‘should’ be developed in the project and contain requirements that are not vital to completing the project but would be painful if not developed. Can also be defined as;- Important but not vital
- Painful to leave out, but the solution is still viable without it
- May need an alternative method to cover the functionality of the requirement, such as a spreadsheet.
Could have
Could have requirements are the “nice to have’s”, where the requirement does provide a meaningful improvement in the project but is less important and would have a lower impact if left out. Could have requirements are the contingency for the project falling behind on time, to keep the quality fixed while keeping to the time and cost set out, these are the first requirements to be dropped. Therefore, the list of requirements should contain around 20% could have requirements.Won’t have this time
These are requirements that have been decided before the project starts that will not be completed this time. The ‘this time’ part is important as the features should be developed at a later time once the initial minimum usable subset has been reached.Summary of Agile projects using MoSCoW prioritisation
Overall, splitting a list of requirements into the MoSCoW sections of Must have, Should have, Could have, and won’t have this time is a good way for a project team and project managers to decide which parts of the system should be developed by the solution development team first to reach the Minimum Usable Subset. MoSCoW prioritisation also sits at a higher level in project planning and a lower level at timebox planning, to read more in this previous blog.How does this apply to timeboxing?
Timeboxes are usually two week chunks of a project which end a deliverable, such as a new feature or improvement. In DSDM agile there are two types of timeboxes, a ‘stuctured timebox’ and a ‘free format timebox’.Structured timebox
The structured timebox gives the team a framework to work around, setting five phases to be worked through.Kick-off
The first phase of the stuctured timebox is the kick-off where the team meets to understand the timebox objectives and decide if they are realistic for the timeframe. This phases should take 1-3 hours for a two week timebox.Investigation
The investigation phases of the structured timebox usually takes between 10 and 20% of the overall timebox and focuses on detailing the requirements and products to be delivered at the end of the timebox. This includes- Timebox deliverables
- Acceptance criteria
- Measures of success