How to create user stories from traditional requirements?
When I coach teams, many times, I see the requirement analysts; often feel uncomfortable to understand the difference between a user story and traditional requirements.
I was talking to a requirements analyst last week, and he was saying
“My company started to go the agile way, and was told to write requirements in User Stories. I have no idea on how to write user stories. Do we still need requirement documents or not at all?
I see the concern expressed is one of the most common one that makes people nervous.
It is hard to figure out how to break the big requirement specifications into smaller chunks of work doable in iteration. Here are few tips and tricks that help to slice the big requirements documents to user stories.
Traditional requirement documents have features specified by each module or milestone.
Tip1: Pick one feature at a time and prioritize
Take each module or big feature from the traditional document, and understand
- Who is the user of that functionality
- What is the purpose of that requirement
- Why does he need that functionality
The “Why” in the last point will tell you the actual business value the end user gets from the feature. It also helps you to assess whether the end user really needs that feature. If you see that there is no real business value in building feature, then push it to the bottom of the stack. The aim is to identify the most important big rocks that are useful for the end user to build his system.
Tip 2: Break the big feature into small chunks
Now this big rock cannot be obviously built in a 2 weeks or 4 week iteration. Obviously it needs to be broken down into smaller pieces.
Start splitting down the requirements into smaller pieces. As you identify each smaller requirement, try to come up with the functionality aka the acceptance criteria that tell us whether we are building the right feature.
Tip 3: Support it with other artifacts
One myth that many had in their minds is, a user story and acceptance criteria is just a bulleted list of sentences. However that is not true!
While writing the user story and acceptance criteria, it is Okay to support it with all additional artefacts that are needed. For example: any wire frame, business rule document, any architecture diagram etc. but ensure you attach the bare minimum things without investing lot of time and the developer understand the intent of the story.
Tip 3: Make sure the requirements are clear
- Ensure that conditions of satisfaction for each story is identified aka the acceptance criteria that helps build the right functionality.
- Write down the tests that can be run verify whether the right functionality is really implemented, aka the acceptance tests that confirm the acceptance criteria is met. Running these acceptance tests would qualify the story as a DONE and accepted story by the end-user.
- Dependencies cross the stories and have them specified in the same user story for reference. Example, Send email story is dependent on Create email story.
- Parent user story i.e the big rock, so that we know what would be finally built once these smaller rocks are done.
- Any assumptions like how will you demonstrate the small rock to the end user, example any test container that you may want to use till the actual test environment is ready.
Tip 5: Repeat and rinse
Repeat all the above steps until a feature in your traditional document is covered.
Repeat the same again and again!
To summarise, take the a big requirement specification document, break it down into feature, break it down into smaller requirements, prioritize them, take the most important ones from top of the stack, capture enough details in the form of acceptance criteria aka the condition of satisfaction. This way you are nailing down on the most important requirements, releasing them to team early to build them, so that ROI can be realized faster.
Do you think this way of breaking the big rock into smaller ones, and building them is better than building the bigger rock at one go? Of course I agree that, there is a need to integrate back all the smaller pieces.