Chapter 18: Appendix A Glossary
Previous chapter: 17 Tailoring the DSDM Approach
Appendix A glossary
|
Term. |
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. | |
| Benefits Assessment |
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. | |
| Development Approach Definition |
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. |
| Deployed 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. | |
| Development Timebox |
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. | |
| Evolutionary Development |
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. | |
| Feasibility Assessment |
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. | |
| Foundation Summary |
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. | |
| Instrumental 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. | |
| Management 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 SubseT |
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. | |
| Prioritised 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 Questionnaire |
PAQ | The DSDM questionnaire, based on the Instrumental Success Factors which helps flag potential risks to a successful DSDM project. |
| Project Governance Authority |
A panel of corporate decision-makers who decide whether projects should proceed or not. | |
| Project Review Report |
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 Investment |
ROI | The concept of an investment of some resource which yields a benefit to the investor. |
| Solution Architecture Definition |
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. | |
| Test-Driven Development |
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 Reference |
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 Record |
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 . |
|
| eXtreme Programming |
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)