up appropriate screens for entering requirements (Figure 8), defining timeboxes (Figures 9 and 10), and MoSCoWing the requirements across timeboxes (Figure 11). Note that we consider timeboxes and iterations to be synonymous. This is a result of our experience in managing client and supplier expectations with escrow and billing cycles, and it represents a significant departure from DSDM.
Figures 8 and 9
Requirements are held in a flat list format, although it is possible (when editing a requirement) to upload a supporting document. This allows Use Cases to be supported.
Timeboxes (or iterations) are defined by start date and end date. Overlapping is permissible since work may be allocated to groups operating in parallel. We have included a separate date for reviewing the products of the iteration (i.e. the incremental release). This may not necessarily be the same day as the final day of the iteration, but it would normally be close to it.
Figures 10 and 11
The MoSCoWing of requirements is done on a timebox-by-timebox basis. All requirements are initially MoSCoWed as “Won’t”, which makes them available for inclusion in any timebox. Once a requirement has been included as a “Must”, “Should”, or “Could” for a particular timebox, then it will no longer be available for inclusion in other timeboxes.
It should be noted that a “Should” at timebox level is not necessarily a “Must” at the project level. We have found that project level “Musts” are fluid, and that higher level classifications are (in practice) driven by what happens at timebox level. As such, DEV Folio does not support the direct linking of timebox level MoSCoW classifications with project level ones. This has proven to be expedient, but it is also a departure from the usual approach to MoSCoW analysis, and we may revisit this issue in future publications.
MoSCoWing is a 3 way conversation between supplier, client, and project manager. The client will provide input on what should be done and when, and how important each item is. The project manager will then negotiate the spread across the available timeboxes with the supplier. Note that the difficulty and effort are entered for each requirement in the timebox during this discussion.
All “Musts” have to be delivered in order for the iteration to be considered a success. Any “Shoulds” or “Coulds” which have not been delivered can be amended to “Won’t” which frees them up for re-allocation to other timeboxes.
It can therefore be seen that the DEV implementation of the Delivery Stage represents a fairly canonical (albeit tool supported) realisation of the DSDM Engineering Phase. However, there was one supplementary modification which we made. This was the inclusion of a graph (a “Highlight Chart”) which tracks the implementation of requirements as they are dealt with (see Figure 12).
The Highlight Chart is risk driven, and leverages the product of difficulty and effort recorded during MoSCoWing to elicit a graph of project risk reduction. The sum of products represents 100% of the project risk; when the project is 100% complete, all risks will have been mitigated. Also, when the project has mitigated 50% of the total risks (expressed as difficulty x effort), then the project will be more likely to succeed than to fail.
We consider this risk-driven approach to more useful than Burndown Charts, which can mislead due to the varying granularity of requirements.
Management of Products
Our PRINCE2 configuration specifies of the roles, management, and work products we usually need (see Figure 1). As can be seen, this is somewhat more than the absolute minimum required for PRINCE2 compliance. This is because