Turning Requirements into User Stories

Perhaps you’re an agile team and you’ve been handed a stack of traditional requirements. Or maybe your team works in waterfall and you’re looking to transition to agile.

The latter – transitioning from waterfall to agile – is no small change, and it involves entirely re-thinking how your team works, and how you gather the information your team needs to start doing work. The former – taking requirements and writing user stories from them – can be a daunting task.

Whatever the case, if you’re an agile team faced with a stack of traditional software requirements, you may find yourself in a position where you need to turn them into user stories.

Why User Stories?

Traditional requirements promote working in waterfall. This means the time from starting work to getting something functionally usable for end users in a production environment can take weeks, months, or even years. User stories enable teams to adapt agile methodology and deliver smaller functional pieces of work in shorter amounts of time. Instead of writing an entire piece of software end-to-end, a single feature is written, tested, and deployed based on what is needed in the user story.

User stories allow teams to deliver true business value through functionality in iterations. Product owners like this because it is more manageable and easier to predict work timelines and identify risks. User stories also help product owners filter out things that don’t give immediate value. This constant rhythm of work means less in-between time ramping up, because work is continually moving forward.

Requirements vs. User Stories

User stories focus on the user experience, and requirements focus on the product functionality. Let’s look at an example of each:

Requirement: The system shall create daily signup reports.

User story: As a Sales Manager, I want to quickly review new signups so that I can prioritize sales calls.

User stories are user-centric, and requirements are product-centric. We talk more about the difference between user stories and requirements in this blog.

Making the Change

The truth is, turning a large set of requirements into user stories is often not worth the time and effort it takes. If you have a set of requirements already, find ways to track progress against them. But simply calling them “user stories” does not get you anywhere closer to working in agile. As we’ve discussed, user stories and requirements are very different.

If you find yourself in the position where turning requirements into user stories is a must, make sure you read the entire existing documentation thoroughly. Then, organize the information in a way that will help you craft relevant user stories to support the requirements.

Remember, user stories have 3 main characteristics:

1. Persona
2. Action
3. Value

In other words, user stories tell who, what, and why.

Conclusion

There is no single formula for turning requirements into user stories. They are not a 1:1 relationship, in fact many user stories can relate to a single requirement and many requirements can relate to a single user story. If you’re in a position that requires working with requirements in an agile setting, consider the time and effort it would take to turn each of those requirements into user stories before proceeding.