How to Create User Stories from Traditional Requirements.

This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Askshutterstock_172355312

When I coach teams, many times, my attention goes to the requirements analysts, because they feel discomfort trying to understand the difference between a user story and traditional requirements. I was talking to a requirements analyst last week, and he was complaining, “My company started to go the agile way, and I was told to write requirements as user stories. I have no idea on how to write user stories. Do we still need requirement documents? 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.

shutterstock_226347637

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.

shutterstock_167285585

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.

shutterstock_157384295

Tip 3: Support it with other artifacts

One myth that many have in their minds is that a user story and acceptance criteria is only 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 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

shutterstock_140339647

  • 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

shutterstock_205094437

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.

 

 

 

 

 

 

There was an issue loading your timed LeadBox™. Please check plugin settings.