Elephants are not giraffes and user stories are not requirements. They share some traits and you may find them in the same context, but that does not make them the same. Despite that, many believe that user stories are the new requirements because there has to be requirements for a project, right? I give that a double “no”, they are not requirements and that is not anything we really need. User stories are about being able to explore options and seize opportunities. Requirements are about deciding up front and sticking with that.
Is this blog post really necessary? Don’t we all understand the above already? No, I believe that expressions like “the requirements in the backlog” reveals that old thinking where the requirements document is now called backlog and the requirements are called user stories. Then you think you are agile.
Other signs of the misconception is that user stories are given an unique id and stored in a database. This may be just convenient but can also be a sign of thinking in requirement terms.
Putting user stories in a contract has to be a definitive sign of being requirements. The crazy part of it is that a user story is not as precise as a requirement and thus the contract is of little value. Requirements are of course open to interpretation but the techniques used to write them strive hard to remove any ambiguity. Requirements are also resistant to change, as they are used in project contracts. To change or add requirements, you need to take it through the CCB, Change Control Board. See below for more on contracts.
So what are user stories? Think of them as planning instruments. Since agile is about delivering value, the planning instrument is about values. We prioritize by user stories, we estimate them and we decide in which sprint we will implement them. All typical for a planning instrument, so do not try to make them into something else.
The power of the user story is in the dialogue that it sparks. Instead of handing over a requirement specification that are interpreted by implementers and testers, a one-way communication, we have multiple skills involved in the discussion for each feature we add.
Since the stories do not carry much meaning, we can throw away them once done. We may very well keep statistics on how many story points we have done but that might be all.
But don’t we need requirements? Well, not really. There are of course constraints on how a system will be designed and built. E.g. medical equipment must respect regulation of the FDA. But let us call them constraints.
Still, requirements is a description of a system and surely there is value in that? How can you say that something is bug or not, unless you have requirements somehow? Here I would like to point to the technique of Specification by Example. Once you have decided that a feature shall be realised, you write the business rules as a series of examples in a format that is both human readable and executable. From those specifications, it is clear what the system does and should it go astray due to changes, the specifications will go red indicating exactly which business rule has been broken. That change will not slip through the build pipeline.
As I have written before, a definition of bugs should be simple and precise. Bugs are things that destroy information and that is bad, regardless if there was a requirement or not, covering that exact case.
Contract
(by Mattias Skarin)
So what do we use instead of requirements to validate we are achieving what we asked for? We use Agile contracts. Agile contracts helps us focus on the thing that matter, achiving an effect goal together and solving user needs, instead on getting lost in a forest of details.
When you think about a contract consider this: The moment you need to pick up your contract to validate if your partner has messed up something else has in your process has gone horribly wrong. A contract should build trust between provider and seller to transcend details, not get lost amontg them.
Summary
- Although both elephants and giraffes have four legs, they are different animals.
- User stories are not requirements, they are planning instruments.
- The closest to requirements is Specification by Example
References
Ron Jeffries post from 2001 where he says: “… uses the planning game to select user stories …”
An article on Scrum Alliance web “New to user stories” where William Nazzaro and Charles Suscheck compares requirements and user stories.
Specification by example: Wikipedia and our course by the man himself: Gojki Adzic
Excellent clarification of distinctions and commonalities. Thanx. Additionally many people confuse the card with the User Story. The User Story is told in the conversation for which the card is merely an anchor(a promise to have a conversation). Alas IME this important and most value adding part in 3C is often the most neglected.
Well, the requirement isn’t the elephant, the requirement is a leaf eating animal. The designer will pick the elephant or the giraffes. The customer needs a leaf eating animal, that’s the delivery. It can also be a monkey. Next sprint the monkey may change in an elephant because a new requirement is that it should not climb trees and needs to stand on the ground.
I think the US should be written differently, and then it are requirements. US should describe what must be fixed (tree gets to big -> tree should be trimmed -> animal will eat leafs.), not what should be build (get elephant).
Requirements by example will take away the interaction between team and PO to fix the problem, the team will just build as asked.
This is beautiful. I always thought there was something odd about hearing that user stories were requirement.
Thanks so much for this Per. I will definitely use this as a reference material for my use.
You have surely blessed me today
Regards
You’re welcome 🙂