Prioritising requirements
DSDM Atern is an agile methodology that defines a useful technique for prioritisation which can be used to control the overall scope of a project and to control iterative development.
DSDM Atern refers to a prototyping cycle as a timebox which it defines as a period of time with a fixed duration. This means that time is not a flexible quantity, and missing deadlines is not permitted in a DSDM Atern project. Likewise, DSDM Atern insists that the budget for a project is also fixed, and that the cost of a project must not increase over time. The three dimensions of time, cost and scope are sometimes referred to as the iron triangle, and together they define the output of the project. In many projects, the scope of the project - the list of features - is the fixed dimension, and time and cost are flexible. However, this can lead to missed deadlines and cost over-runs. Because DSDM Atern fixes time and cost, the only other source of flexibility is in the project scope.
MoSCoW prioritisation
In order to allow flexibility in scope, DSDM Atern uses the MoSCoW prioritisation technique. This is a four-level scheme which is applied to the requirements that will be attempted during a timebox. The four priority levels are described in the table below.
| Label | Interpretation |
|---|---|
| M | Must-have items are essential for the product or for the business case of the project |
| S | Should-have items are not essential, but are nevertheless important for the quality of the finished product |
| C | Could-have items are features which would be nice to have, but which would not compromise the overall quality if they were missing |
| W | Won't-have items are not included in the current scope - this final category is more important than it first appears |
MoSCoW at project level
Clients may not differentiate between different requirement priorities until prompted. They can have an all-or-nothing view of the project which you need to move them away from. This is a process of education in that you may have to explain MoSCoW to them so that you can come to an informed agreement over the scope of the project.
Two important things to remember during these early negotiations are:
A good scope definition will have an even spread of requirements across the M, S and C categories
Spreading the requirements across categories is what gives your project flexibility. Without this, you will not reap the full benefit of an agile approach.
and
You should actively try to reduce the number of items in the M category
Because the M category represents the essential requirements for the project, it is essentially your definition of success. Once you have achieved all of the Must-have items, you have by definition achieved a successful project. The shorter the list, the more quickly you can reach success.
MoSCoW at timebox level
At the start of a timebox, DSDM Atern says that there should be a list of requirements that will be attempted within the time available. MoSCoW is applied to this list so that there are items in each category, and that according to your best estimates, there is enough time to complete all the Must-have and Should-have items. This is how DSDM Atern builds in flexibility: if things go well, you finish all of the planned items and you can also include some of the Could-have items as well. On the other hand, if things do not go to plan (which is more likely), some of the Should-have items can be dropped without compromising on the essentials. Putting items in the Won't-have category ensures that no-one on the team is tempted to spend time on things which are not immediate priorities.
The red line in the diagram below represents the point that is reached in the requirements list at the fixed end point of the timebox. Careful scoping should ensure that at this point all Must-have items have been done and ideally some of the Should-have and Could-have items as well.
At the end of a timebox, the delivered features are compared with the original prioritised list. This provides an opportunity to take explicit decisions about the remaining requirements by adjusting their priorities. Something that was a Should-have in the previous timebox, for example, can be promoted to a Must-have item in the next. Alternatively, it could keep the same priority or be demoted to a Could-have or a Won't-have. In this way, priorities are constantly re-evaluated throughout the project ensuring that the team focuses on what is most important. If the priorities change by a large degree, this could trigger a discussion with the client. This is especially true when something is moved into the Won't-have category since this means that the team no longer expects it to be included in the final product. This is called de-scoping, and is a natural part of a DSDM Atern project.
Further reading
A Comparison of Nine Basic Techniques for Requirements Prioritization