10 ways stories aren’t like requirements
It’s easy to make Agile fail at the first hurdle: the story.
Too many organisations seem intent on sneaking requirements back into the picture. So, very briefly, here are 10 ways stories are different from – in fact opposed to – requirements.
|1.||Stories describe complete units of valued capability – not a detail in a larger solution.|
- So they can be implemented in isolation from one another.
- So when even a single story has been delivered, the organisation has already benefited…
- … and development has already started to pay for itself.
|2.||Stories are short and easy to read.|
- Though only as short as they need to be. Although they can accommodate any amount of detail, they are mainly intended to record what the user is looking for in quite general terms.
- As delivery always happens shortly after stories are finalized and the relationship between developer and user is normally close and frequent, little is lost by having ‘lightweight’ stories rather than ‘heavyweight’ requirements.
|3.||Stories include their own verifiable acceptance criteria.|
- So you can tell straight away whether they can be delivered, or even make sense.
- Like the story itself, acceptance criteria are written in such a way that the story is tightly focused.
|4.||Stories, acceptance criteria and acceptance tests are all written by the same group – not disconnected specialists.|
- So they can be validated directly with the owner.
- And gaps and conflicts are far less likely to arise.
|5.||A story is a talking point for working with users – not a fixed specification.|
- A vast amount of effort is expended on writing requirements that will almost certainly be inaccurate and will probably change as development proceeds.
- Stories represent a ‘statement of intent’, not a contractual (internal or external) commitment.
- So they’re negotiable right up to final delivery.
|6.||Stories are only as detailed as the developer needs them to be at that moment – not fully defined by a standard.|
- The developer will get the details from the user – a much better source than a long, difficult and frequently incorrect document.
|7.||Stories are delivered as part of a rapid implementation process – not buried in a massive project or programme.|
- So value begins to be delivered almost as soon as the ink is dry on the story card.
- The bottlenecks & integration crises of pre-Agile lifecycles are replaced by a smooth flow of actual value.
|8.||The status of stories is always transparent – not obscured by bureaucracy.|
- So we can always tell when things are going wrong, and where we need to take action.
|9.||Stories are easy – and expected – to change, not under formal change control.|
- It is naive to expect what the user needs to go unchanged – not just over a long period but even over a short release process, during which the user will be shown what their story means in the most direct way possible – working software.
- Everyone who needs to agree is already ‘in the room’, so why force them into a rigid change control process?
|10.||Stories are on constant view to – and under constant review by – the team, by visiting stakeholders and by neighbouring developers.|
- So new ideas, unexpected impacts, creativity, innovation – all are permanently maximised.
- On the other hand, not all stories are a good idea. We should challenge them when they stop making sense.
Regrettably, any organisation that does not take these differences seriously – and they could hardly be more radical – isn’t going to last long in the Agile universe.