As a (role), I want (feature), so that (benefit)
i.e. As a standard user, I want to be able to search for matters, so that I can easily select the correct matter from a list
With minimal training, this format will allow you to catalog a list of requirements for your new solution. Not only are you as a BA listing your requirements with minimal effort, but they are already in a format that is appropriate for all levels of the business to read and understand.
A colleague pointed out that user stories are extremely similar to standard user cases. This is true, with a few important differences.
- A user story is a singular, independent unit of requirement - this allows it to be developed and tested according to it's priority in the backlog
- User stories are written by the business users - this not only gets them to think about what they want, but also ensures that as a BA I'm not interpreting what they want into what I think they want.
- User stories help create buy-in from users - By making the business users write their own user stories, you are encouraging the users to take ownership of their solution. If they can't see the benefit of it, then stop what you are doing right now, take a step back and look at the big picture
You can also make user stories testable with scenarios.
Scenario 1: Scenario description
Given [situation]
And [another situation]…
When [event]
Then [outcome]
And [another outcome]…
So how do you know which user story to work with first? The proritisation should come from the project sponsor (with guidance if necessary).
An easy and visual method I'm experiementing with on one project is through Agile Zen, listing various stages including backlog, ready, completed and archive. The project team is able to log in and view the progress of the various requirements at any point.
So, you get the business user to write the user story, it's self documenting and it help creates buy in. What's not to like?

No comments:
Post a Comment