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.
Best Answer
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.