How should I translate a requirements document into user stories?

Question

I received a big old fashioned requirements document. But my team is working using agile methods (a combination of scrum and kanban), so what we need is user stories.

Is there some guidance for "translating" requirements into user stories?

Obviously I don't want to start from scratch, as someone did good work to compile that doc. But in its current form it is essentially useless. The doc is hundreds of pages long, and not written from the user's perspective. Translation may take as long as starting from scratch...

So, I'd appreciate tips from someone who's faced this before.

For example, I've been looking for related major sections, and converting them to epics. Another old trick, looking for nouns and verbs and convering those to roles, actions, entities, etc.

Answer 1

There's no shortcut. What you have is great if formally verifying that system requirements is a requirement of the project. If formally verifying system requirements is not a requirement then you can usually skip the formal requirements. In any event, creating use-cases/user-stories is always helpful, so you should create them, even if they are just a slimmed-down version of what you'd normally do.

Other than that it is simply processing each requirement in a loop. Read each requirement identify a user-story that covers the requirement and map the requirement to the user-story. If the user-story doesn't already exist then create a user-story for the requirement.

It may seem like a lot at first, but it really shouldn't take all that long to have a first cut. Most of the time, formal requirements end up being grouped into related stories anyways so it won't be surprising to knock out 10+ requirements at a time as a user-story is created. What will take longer is getting your questions answered about the requirements that you don't quite understand. You would have had to get these answered eventually, it's just that you've identified them now instead of later.

It is likely that you'll run across quite a few requirements that will not fit cleanly into 1 user story. In those cases you should derive more specific requirements that will fit more cleanly into individual stories. Map the derived requirements to the user-stories and maintain trace-ability to the original requirements. That's why there's system level requirements and software requirements. (Depending on the project there could also be a in-between level of requirements also).

Now that you have 'formal requirements' and user-stories with those requirements mapped to them then it becomes a breeze to write test procedures to formally verify your requirements based off the user-stories.

To summarize, sorry there's no shortcut. If your program needs to formally verify requirements then having the formal requirements already written makes your life far easier. It is much, much, much harder and more time-consuming to write a formal requirements document than a bunch of user-stories even with mapping the formal-requirements to the user-stories.

Answer 2

But my team is working using agile methods (a combination of scrum and kanban), so what we need is user stories.

This is a misconception. Neither Scrum nor Kanban require that requirements be specified in user stories. Both are silent on the issue.

The Scrum Guide refers to "Product Backlog Item". These items have only a few attributes - description, order, estimate, value. There's nothing about the format or style required by Scrum, although you do often find the User Story format used. Kanban has even fewer requirements on items than this.

Instead of trying to convert your requirements specification into User Stories, make sure that your requirements meet the characteristics of a good requirement - cohesive, complete, consistent, atomic, traceable, current, unambiguous, have an importance specified, and are verifiable. Then, identify any technical dependencies between requirements and ensure they are prioritized appropriately.

If you're embracing Agile, you'll recognize that your requirements specification is not "finished" - these requirements may change. Instead, focus on the principles of agile software development. Iterate quickly - implement slices of the functionality specified in the requirements specification and get it in front of people who can evaluate the software and provide feedback to incorporate into future iterations. Have your development team work closely with subject matter experts, product managers, and stakeholder representatives to understand the users and their needs. Focus on the higher priority requirements first - you may not actually need to implement everything to be acceptable by the users and can maximize work that isn't done. Reflect and improve on how the team works.

Answer 3

I apologize for being a little bit "scrum pedantic" but am I the only one surprised that no Product Owner is mentioned ?

It's the meaning of @Thomas_Owens's answer: You can transform the requirements documentation in what suits your team's process but if no PO is here to help you (read: inform you) then it has only little value if you cant' prioritize and refine the items :).

I guess that you have only little choice about this situation but personaly, what I would do first with this document is to find the person that can explain every bit of it to me and nominate it as PO. Maybe the one who wrote it ?