2

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.

Improve this question
10
  • Why the downvote?
    – grokky
    Oct 24, 2017 at 17:28
  • I didn't downvote, but you might be overthinking this. Read the requirements, work out "as a _______ I want to _______ so that ______" phrases based on what the requirements say, and write the phrases down. Achievement unlocked.
    – Robert Harvey
    Oct 24, 2017 at 17:31
  • I can't be the first one to encounter this problem. There must be some advice or tips to follow. The doc is hundreds of pages long, written from the analysts perspective, not the user's. So it'll take as long to convert it as to capture user stories from scratch - BUT, I want to know if there are some clever techniques to save time. For example, I've been converting major related sections into epics.
    – grokky
    Oct 24, 2017 at 17:34
  • 4
    Also, note that you don't necessarily need user stories. You could put each requirement into the sprint, directly. However, making the effort to create epics and user stories will potentially help the team understand the requirements better and provide a high-level view of the work to be done.
    – Robert Harvey
    Oct 24, 2017 at 17:38
  • 2
    IMO, there's no much point in simply translating the requirement specification into user stories without involving the actual users, because that way you will not capture the needs and intentions of the users (why they need the system and how they would use it). Instead, you'll simply change the form of the spec. Or, at best, you'll create something that represents your interpretation of what the users need, based on the requirements document - and this interpretation may be quite a bit off.
    – Filip Milovanović
    Oct 24, 2017 at 18:00

3 Answers 3

Reset to default
3

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.

Improve this answer
1
  • This is exactly the kind of advice I was looking for, thanks Dunk!
    – grokky
    Oct 25, 2017 at 5:14
8

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.

Improve this answer
14
  • 1
    @grokky Just because a requirement is written from a business perspective doesn't mean it's a "waste of time". That's a very dangerous line of thinking. But a strong Product Owner, subject matter expert, or other stakeholder representative will help you understand the rationale behind the requirements and ensure you work on the ones that add the most value first. Don't focus on the formatting so much - focus on the content specified.
    – Thomas Owens ♦
    Oct 24, 2017 at 18:03
  • 2
    @grokky: Thomas' point is that the nature and form of the requirements specification is not what makes a process agile. If you need to fix the requirements, that needs to be done whether you use agile or waterfall.
    – Robert Harvey
    Oct 24, 2017 at 18:37
  • 2
    @grokky: When turning this requirements spec into an agile product backlog, put those useless items as close to the bottom of the backlog as possible. That will make them the first candidates to be dropped when time runs out on the project.
    – Bart van Ingen Schenau
    Oct 24, 2017 at 18:52
  • 3
    @grokky: Regardless of what methods you use for capturing requirements (user stories, system-centric, etc.), the first set of requirements will contain items that users in the end are not going to use. Even if it is the users themselves that come up with the requirements.
    – Bart van Ingen Schenau
    Oct 24, 2017 at 18:55
  • 1
    @grokky your comments lead me to believe that you do not like the current document because it does not buy into the buzzword bingo that is Scrum and the typical implementations put in place by managers who read about it in CTO Magazine but otherwise have no idea what it is. Specifically, just because a document is "old school" does not make it bad - it might be, it might not be. I would start by decomposing it into bite-sized pieces representing development tasks that meet the requirements in Thomas' answer and can be assigned out. Then you will have your "stories."
    – user22815
    Oct 24, 2017 at 21:53
2

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 ?

Improve this answer
3
  • Very true, but in this case there is no PO, and the client doesn't use scrum (we use some aspects of scrum however). They just wrote a requirements doc and dumped it on our desk. And management already said "no problem, we'll do it!" of course. This is very common behavior... They aren't a tech company. So we need to use it as is as recommended in the other answers, sometimes the easiest way is best.
    – grokky
    Nov 1, 2017 at 8:07
  • I really empathize with you. No chance you access to the client on a regular basis ?
    – Keufran
    Nov 2, 2017 at 7:33
  • Lol no... you know how it is - not everyone out there does things the new "agile" way. Most companies still do things the old fashioned way so we need to do what we can. We get to "bother" them with questions once a week... very agile! :) Regardless, their specs are actually very good, so we're working off of them directly, without converting to stories or anything like that.
    – grokky
    Nov 2, 2017 at 16:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.