MoSCoW prioritisation for Timeboxes in Agile projects

by | Nov 25, 2021 | 0 comments

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
This phases ensures that the timebox has a strong start and guidence for the refinement phase.

Refinement

Refinement is where the majority of the work is done, usually 60 to 80% of the overall timebox, developing and testing requirements in line with the aggreed deliverables and criteria. Refinement ends with a review which is used to inform the consolidation phase on what is outstanding and what is complete.

Consolidation

Consolidation is where the requirements specified in the investigation are checked to ensure that they are deleloped to the expected quality and criteria set in the investigation phases. This phase usually takes between 10 and 20% of the overall timebox.

Close-Out

Close-out is the final phase in the structured timebox where the deliverables are formally accepted by the Project Level, followed by a timebox retrospective to learn from the timebox and take actions to improve future timeboxes.