Chapter 18: Appendix A Glossary

Previous chapter: 17 Tailoring the DSDM Approach

Appendix A glossary


Abbreviation  Detail
80:20 rule   A rule of thumb stating that 80% of consequences stem from 20% of causes. Also known as the Pareto Principle; it advocates pragmatism on a DSDM project. The value of the Pareto Principle is that it reminds you to focus on the 20% that matters.
Agile   A style of working where requirements and solutions evolve through collaboration between self-organising, cross-functional teams. Agile promotes adaptive planning, evolutionary development and delivery, a timeboxed, iterative approach and encourages rapid and flexible response to change.
Agile Manifesto   The Agile Manifesto defines the approach and style that is fundamental to all Agile approaches. It was created in 2001, at a summit attended by representatives of all the Agile methodologies.
  A DSDM Product. It describes how the benefits have actually accrued, following a period of use in live operation.
Business Case   A DSDM Product. Baselined at the end of the Foundations phase, it provides a vision and a justification for the project from a business perspective.
Bottom Up   A style of estimating. Using this approach, each component is estimated individually and then the estimates are summed to find the total effort.
Cycle   DSDM defines Iterative Development as an informal cycle of “Thought, Action, Conversation”.
Delivery Plan   A DSDM Product. It provides a high-level schedule of Increments for the project and, at least for the first/imminent Increment, the timeboxes that make up that Increment.
DAD A DSDM Product. Baselined at the end of the Foundations phase, it provides a definition of the tools, techniques, customs, practices and standards that will be applied to the Evolutionary Development of the solution.
  This is a baseline of the Evolving Solution, which is deployed into live use at the end of each Project Increment.
Deployment   The DSDM lifecycle phase which focuses on getting the solution (or part of it) into operational use.
  A fixed period of time, part of Evolutionary Development, where development and testing of the Evolving Solution takes place. Typically 2-4 weeks long. See Timebox.
Done   A common term used in Scrum - an item is “Done” (completed) when it meets all the criteria that have been defined for it (“Definition of Done”.) Done is binary - an item is either Done or Not Done.
  The DSDM lifecycle phase used iteratively and incrementally to investigate the detailed requirements and evolve them into a viable solution
Evolving Solution   A DSDM Product. It is made up of all appropriate components of the final solution together with any intermediate deliverables necessary to explore the detail of requirements and the solution under construction. At any given time, such components may be either complete, a baseline of a partial solution, or a work in progress. They include, where valuable: models, prototypes, supporting materials and testing and review artefacts.
Feasibility   The DSDM lifecycle phase which gives the first opportunity for deciding whether or not the project is viable from a technical and/or business perspective.
  A DSDM Product. It provides a snapshot of the evolving business, solution and management products as they exist at the end of the Feasibility phase. It may be expressed as a baselined collection of the products or as an executive summary covering the key aspects of each of them.
Fit for Purpose   Something that is good enough to do the job it was intended to do.
Foundations   The DSDM phase to establish firm and enduring foundations from the three perspectives on a project of business, solution and management.
  A DSDM Product. It provides a snapshot of the evolving business, solution and management products as they exist at the end of the Foundations phase. It may be expressed as a baselined collection of the products or as an executive summary covering the key aspects of each of them.
Function / Feature   See Requirement.
Increment   An element of the Evolving Solution, comprising a collection of one or more features which, as a group, have meaning/value for the business. One or more Increments may form a Release.
Increment Timebox   Timeboxing can be applied at increment level and an Increment Timebox comprises the time fixed by the sum of the Development Timeboxes for this Increment. See Timebox.
Success Factor
ISF A key behaviour or style of working that is seen as instrumental to position DSDM projects for success. Where these factors cannot be met, they represent a significant risk to the DSDM approach.
Iteration   1. A general term for working in a cyclic way, where several attempts are made in order to get a more accurate or beneficial result.
2. One cycle of development and testing which takes place (one or more times) inside a Timebox and which finishes with a Review.
3. In eXtreme Programming, Iteration equates to a DSDM Timebox.
MoSCoW   A DSDM prioritisation technique, mainly used on requirements although also useful in other areas (such as testing). M stands for Must Have, S stands for Should Have, C stands for Could Have and W stands for Won’t Have This Time.
Approach Definition
MAD A DSDM Product. Baselined at the end of the Foundations phase, it reflects the approach to the management of the project as a whole and considers, from a management perspective, how the project will be organised and planned, how stakeholders will be engaged in the project and how progress will be demonstrated and, if necessary, reported.
Minimum Usable
MUST The minimum set of requirements needed to deliver a usable solution – the “Worst Case” basic deliverable. The Minimum Usable SubseT is defined as the Must Haves. Provided the (MUST) MoSCoW rules are properly applied, delivery of the Minimum Usable SubseT is guaranteed.
Post-Project   The DSDM phase which takes place after the last planned Deployment. It is used to assess the business value delivered by the project.
Pre-Project   The DSDM phase where the initial idea or imperative is formalised in order to initiate a project.
Principle   A ‘natural law’ which acts as an attitude to take and a mindset to adopt on a DSDM project.
Requirements List
PRL A DSDM Product. Baselined at the end of the Foundations phase it describes the requirements that the project needs to address and indicates their priority with respect to meeting the objectives of the project and the needs of the business.
Project Approach
PAQ The DSDM questionnaire, based on the Instrumental Success Factors which helps flag potential risks to a successful DSDM project.
Project Governance
  A panel of corporate decision-makers who decide whether projects should proceed or not.
Project Review
  A DSDM Product. Updated at the end of each Increment it: captures the feedback to confirm what has been delivered and what has not; captures learning points from the retrospective focusing on the process, practices employed and contributing roles and responsibilities; where appropriate it describes the business benefits that should now accrue through the proper operation of the solution delivered by the project up to this point. After the final Project Increment a Project Retrospective, in part informed by these Increment reviews, is prepared as part of the closure of the project.
Project Timebox   Timeboxing can be applied at project-level and a Project Timebox comprises the time fixed by the sum of the Increment Timeboxes for the project. See Timebox.
Prototype   A piece of work that demonstrates how a given objective can be or has been achieved or to prove a concept.
Release   A collection of Features (developed and tested elements of the Evolving Solution) being deployed into operational use. A Release may comprise one or more Increments.
Requirement   Something the final solution needs to be able to do (functional requirement) or do to a certain level (non-functional requirement). Similar words: function, feature, User Story.
Retrospective   A Facilitated Workshop to look back on a recent event and to assess what went well and what could be improved.
Return on
ROI The concept of an investment of some resource which yields a benefit to the investor.
SAD A DSDM Product. Baselined at the end of the Foundations phase, it provides the design framework for the solution.
Scope   A description of what the solution will do and what it will not do. This could be a list of features and/or a description of areas of the business that may or may not be affected.
SCRUM   One of the Agile approaches, with a strong focus on the team
management process. Scrum’s focus is on a flexible, holistic product development strategy.
Servant-Leader   Servant-Leader is the style of leadership that Agile projects aspire to, in particular from the Project Manager and Team Leader roles. A servant-leader shares power, puts the needs of others first and helps people develop and perform as highly as possible.
Stakeholder   A person, group, organisation, member or system who either affects or is affected by actions taken by the Project or the Team.
Story   See User Story.
TDD An approach whereby a test is written before the solution is built, thus ensuring the requirement is understood and testable. TDD aims to encourage simple designs and inspire confidence. It is most commonly applied in an IT environment but is now gaining interest as a technique outside IT.
Team Board   A large graphical representation of project/Timebox information kept plainly in sight within an Agile team’s shared workspace. It shows anyone who views it information they care about, and thus avoids the need to keep asking the team for information. This ensures more communication with fewer interruptions. Team Boards can contain most types of charts used in Agile development. Burn-down charts, task boards, planning boards and storyboards are among the possibilities. A Team Board is usually hand-drawn
or printed but can also include computer-generated charts and electronic displays. (Sometimes called Information Radiator, Big Visible Chart or KanBan Board).
Terms of
ToR A DSDM product created Pre-project. It is a high-level definition of the over-arching business driver for, and top-level objectives of, the project.
Timebox   A fixed period of time, at the end of which an objective has been met. The objective would typically be a deliverable of some sort. Typically Timeboxes operate at development level, but timeboxing can also be applied at project and increment level. A timebox is managed by adding or removing content in order to meet the timebox objective and the deadline. (See also Sprint [Scrum] and Iteration [XP]).
Timebox Plan   A DSDM Product. It is created for each Timebox. It elaborates on the objectives provided for that Timebox and details the expected deliverables, along with the activities to produce those deliverables and the resources to do the work. The Timebox Plan is created by the Solution Development Team and is often represented on a Team Board as work to do, in progress, and done.
Timebox Review
  A DSDM Product. It is created for each Development Timebox, capturing the feedback from each review that takes place during that Timebox. It describes what has been achieved up to that point together with any feedback that may influence plans moving forwards. Where appropriate, e.g. in a regulated environment, it may provide a formal auditable record of review comments from expert Business Advisors and other roles.
Top-Down   A style of estimating using approximate sizings and groupings. For example, estimating 10 small components at typically one day each, 20 medium components at typically three days each, three complex components at typically five days each. These groups are summed to give an approximate estimate for a solution where the low level detail is probably still unknown.
Transparency   This describes openness, communication, and visibility. Transparency means operating in such a way that it is easy for others to see what actions are being performed and what progress is being made.
User Story   A requirement expressed from a user point of view and with
associated acceptance criteria. The usual format is: As a I want so that .
XP One of the Agile approaches with a strong focus on technical (IT) development techniques. XP is intended to improve software quality and responsiveness to changing customer requirements.

 Next chapter: 19 Appendix B Project Approach Questionnaire (PAQ)


Agile2024 European Experience

See the bigger agility picture this July


24-26 July 2024 | Manchester, UK


25+ talks and workshops covering everything from sustainability and culture to innovation and inclusion.


Book tickets