Using User Stories with PRINCE2 – Part 1
Before I explain User Stories within a PRINCE2 project, I need to back up a little, to set the scene with requirements that them project must ultimately meet and deliver.
A well understood, prioritized and degree set of requirements is vital, but many PRINCE2 projects suffer because of trying to define and a full and detailed set of requirements too early within the project.
Such an approach is counterproductive, restrictive and wasteful – not to mention unrealistic.
Defining detailed requirements to early means either needing to change them later, wasting the original work, or stubbornly sticking to the original requirements and not satisfying the business need.
Experience has shown that the business environment changes as time progress is and this will mean nailing down new requirements as your project continues through its various stages.
With the spread of using an Agile approach, experience has shown that requirements should only be captured at a high-level early within the project.
Put simply, a requirement is a service, function or feature that the user needs.
Suppose your PRINCE2 project is to deliver a sailing dinghy.
In this case, such a requirement would be more feature based:
- The ability to move in the water
- The ability to change direction
- A comfortable place to sit
Now compare those with the following which are not requirements, but solutions:
- An outboard motor
- A tiller or steering wheel
- Seats with safety harnesses
PRINCE2 Requirements
The approach here is to state requirements with reference to what needs to be achieved, without tying them to a specific solution for as long as possible.
This allows for greater flexibility to be retained in how the solution is eventually provided, rather than how they will be met from a specialist point of view.
Any attempt to count of requirements in a solution form too early may constrain what can be achieved within the available PRINCE2 time and budget.
PRINCE2 categories of requirement
There are two aspects here:
- What the requirement does – its functionality and features
- How well the requirement performs against defined parameters – and these include acceptance criteria
Functional requirements
These express function or feature and define WHAT is required
These requirements do not state HOW a solution will be physically achieved
So, the secret here is to state requirements early within your PRINCE2 project as what rather than how, and hence allowing room for flexibility and innovation later.
Nonfunctional requirements
Nonfunctional requirements define HOW WELL, all to what level a solution needs to behave.
Solution attributes will be described such as security, reliability, maintainability, availability, performance and response time, etc.
These are among functional requirements may be solution wide, impacting a group of functional requirements, or applicable to a specific functional requirement.
Using PRINCE2 User Stories
Now I will get to the meat of this article.
In a perfect world, the PRINCE2 project mandate will contain the full scope of requirements – all of them accurate, well-defined, consistent, and fixed.
You and I know from the above that this will not happen.
The first process that is triggered within a PRINCE2 project, is pre-project – the Starting Up a Project process.
With the focus on User Stories, the best that can be expected, is to incorporate requirements statements focused on what needs to be achieved without tying them to a specific solution.
Such information would be included within the PRINCE2 Project Brief.
PRINCE2 Customer Quality Expectations and Acceptance Criteria
The two areas that are of most interest here within the project brief are the customers quality expectations leading to the creation of the first draft of acceptance criteria.
Harnessing the power of user stories, these can be used to initially define customer quality expectations, and then used to draught acceptance criteria.
The PRINCE2 method states that pre-project, acceptance criteria will usually be at a fairly high level and hence generic in specifying what is acceptable on what is not.
Often the formal start of your PRINCE2 project, the initiation stage is triggered, and work starts on the assembly of the project initiation documentation.
It is within the PROJECT INITIATION DOCUMENTATION, that refinement of the acceptance criteria occurs.
It is here that user stories can and real value in nailing such acceptance criteria down.
