A very important factor to take into account is whether or not it is obligatory to create these products. If it seems that they do not bring value, that they are created due to bureaucracy, because “our methodology says so”, because “the client requested it”, and we have the sensation of unnecessary work, we should ask whether it is really necessary. It is not obligatory, it is a recommendation of the framework. Textually, we are told the following:
It is also critically important to remember that DSDM products are only created if and when they add value to the project and/or to the solution it creates. The most important thing is that the stakeholders and participants in the project understand what is needed and what is being delivered and that quality is assured. If documents genuinely help achieve this then create them, if not, don’t waste valuable time and effort doing so.
The products include the solution in itself, the main product to create, and the products necessary for helping to develop and maintain it, plus the products necessary for helping with governance and control of the project.
DSDM distinguishes 2 different types of product:
- Products which develop over time. For example, the requirements or solution. Different baselines of this product may be made over the course of the project.
- Products which mark a milestone. Normally at the end of a phase as a checkpoint or to facilitate the governance process.
Additionally, products are classified in 3 categories:
- Business-oriented Products. Focused on detailing business aspects, such as expected benefits, requirements, justification for the project. Marked in orange.
- Solution/technical oriented Products. Focused on defining technical, development, quality management and scope aspects. Marked in green.
- Management/control oriented Products. Focused on project management, including communication, planning of delivery and continuous improvement aspects. Marked in blue.
In addition to this classification, some may be related with governance processes or with compliance with the solution with regard to corporate standards or regulations. These are detailed with a G in a blue circle.
In the following image we can see the 14 products, with the corresponding colour, and with the phase of the project in which it is proposed to create and develop them:
These are the 14 products of DSDM:
- Terms of Reference. Created before the formal start of the project, this is the document which provides a definition at ta very high level of why to initiate the project. Investment of effort is justified in the Feasibility phase.
- Business Case. This provides an overview and justification of the project from a business perspective. It is an evolving document that we create progressively during Feasibility and Foundations, and which we will mark as a baseline for starting development. We will review it periodically to ensure that we are aligned with the objectives of the project, and it will help us to determine whether we should continue with the project, stop it, or refocus it.
- Prioritised Requirements List. High level description of the project requirements, and their relative priority. This product is very similar to the Scrum Product Backlog.
- Solution Architecture Definition. High level design of the framework of the solution. Includes technical and business aspects with a sufficient level of detail to have a clear idea of the scope of the solution, but without limiting development which allows us to adapt to future changes.
- Development Approach Definition. Describes at a high level which tools, practices and standards, etc. will be applied during the development. Following the DSDM principles, the development must be iterative, with incremental deliveries, integrating testing throughout the process. Therefore, it will include the detail of how we plan to ensure the quality of the solution developed.
- Delivery Plan. High level planning (weeks – months) of the incremental deliveries planned, similar to a Roadmap or Release plan. It does not go into detail on the necessary tasks to carry out, but instead the estimated delivery dates.
- Management Approach Definition. Encompasses how we will execute the project from a management perspective: how we will organise ourselves, how we will plan, how we will involve key individuals, how we will communicate and demonstrate progress, etc.
- Feasibility Assessment. At the end of the Feasibility phase we must make a decision on the viability of the project. Will we be capable of undertaking it? In this governance product we will include the products created until now (Business Case, PRL, SAD, DAD, Delivery Plan, MAD), or an executive summary of them. Its approval allows us to go into greater detail to later make the Go – No Go decision before beginning development.
- Foundation Summary. We use this product as a basis for the Go – No Go decision of the development of the solution. It provides us with a sufficient level of detail to estimate whether we will be able to deliver the required solution in the expected terms of cost, time, quality, etc.
- Evolving Solution. The evolving product, the reason for which we have initiated the project. Includes both the developed solution and other necessary components for its use and maintenance, thereby generating different solution increments constructed by the Evolving Solution. At the end of each Project Increment, the Solution Increment moves to a production environment, and becomes the Deployed Solution.
- Timebox Plan. Detail of the Delivery Plan to carry out in an iteration. Includes both tasks to carry out and the update of its status, and the deliverables to produce. This may materialise in the form of a Team Board, with a simple Kanban, for example. Similar to Scrum Sprint Backlog.
- Timebox Review Report. Summary of what has been achieved upon completion of the Timebox. Also captures the feedback of the review at the end of the iteration, and the potential improvements to incorporate. It is similar to the conclusions that we may obtain in Scrum Sprint Review and Sprint Retrospective meetings.
- Project Review Report. Incremental document, with the conclusions and progress after each Project Increment.
- Benefits Assessment. Description of the benefits achieved after putting the developed solution into production. May be completed several months after the end of the project, depending on the justification set out in the Business case.
We remind you once more that these products are not obligatory, being a recommendation of the framework to be considered by the members of the project team. Citing the DSDM:
“Not all products are required for every project and the formality associated with each product will vary from project to project and from organisation to organisation.”
DSDM provides us with good practices for which aspects to take into account in the agile development of a solution, and we must be consistent with the effort required vs the benefits provided for each one of the products.