 |
 |
25.1 Purpose
The purpose of this focus area is to describe how to define and prioritize requirements (or user stories), so that they are in a form that is conducive to working in an agile way (where the requirements are subject to the inevitability of change – see also Chapter 14, Change theme).
25.1.1 Requirements terminology
There are many terms that are used to describe what a product does or how well it does it. In PRINCE2 Agile the conventions in Table 25.1 are used.
| Approximate level of detail | Preferred PRINCE2 Agile terms | Possible equivalent terms |
|---|---|---|
The highest | Project product description | Vision |
High level | Product group Project product description composition High-level requirement | Epic, feature, function, theme, scope |
Intermediate level | Product description Intermediate-level requirement | Epic, feature, function, coarse-grained user story |
Low level | Product description Sub-product Low-level or detailed requirement | User story, fine-grained user story |
Table 25.1 Requirements and equivalent terms
25.1.1.1 Further clarification
The following lists some of the ways requirements are treated in PRINCE2 Agile:
- In order to meet a requirement or produce a product it may be necessary to carry out one or more ‘tasks’. These could appear on a team plan or sprint backlog (not referred to as requirements by PRINCE2 Agile).
- Requirements fall into two types: functional (what it does) and non-functional (how well it does it).
- Throughout the PRINCE2 and the agile communities, many of these terms are used interchangeably (e.g. function, feature, user story, requirement) although they are not necessarily referring to the same thing. Table 25.1 provides the view of PRINCE2 Agile and how it refers to these terms.
- Throughout this manual, the terms ‘requirements’, ‘product descriptions’ and ‘user stories’ are often used interchangeably, as most of the time they are referring to the same thing. The choice of term will depend on which term best suits the context.
25.1.2 The role of requirements
Requirements have a special role in an agile context. They represent the ‘currency’ an agile team deals in. Managing and trading requirements becomes a focal point of the way an agile team works, as less focus needs to be applied to other constraints such as managing time and cost.
Defining a requirement is one thing, defining it well is another! It is essential that requirements are defined well, as this gives a level of precision that actually defines the end product. However, to do this requires the relevant technical skills and the use of good techniques such as interviewing skills and process modelling.
Take, as an example of the importance of requirements, the delivery of a new kitchen. This is what the customer wants and what the project must deliver, as described in the project product description. A business case would have been created in order to justify this. But how does the customer define what they mean by ‘a kitchen’? Does the new kitchen have a dishwasher and an ice-maker? How important are these features? Requirements describe what the customer means by ‘a kitchen’.
|
|
