This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Ask
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. It needs to be broken down into smaller pieces. Start splitting 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
While writing the user story and acceptance criteria, it is Okay to support it with all additional artifacts 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 4: Make sure the requirements are clear
- Ensure that conditions of satisfaction for each story is identified aka the acceptance criteria; That helps the team 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.
- Map dependencies across the stories and have them specified in the same user story for reference. As an example, the “send email” story is dependent on “create email” story. Ensure the top level feature is outlined, i.e the big rock, so that we know what we are looking for once all the user stories are created.
- Outline any assumptions around how will you demonstrate the small rock to the end user, for example any test container that you may want to use until 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.
Decomposition is the same, you are just making it outcome driven instead of activity driven
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.
