Writing a User Story in SCRUM
- Who wants the functionality
- What it is they want
- Why they want it
Who: User Story Format Element #1
The Who (As a role) describes the users of a typical product or system. Some development teams create formal user personas for this. Others generalize types of users into a category.
- Users who are not directly impacted or would be using the product/system sparingly, can be referred to as Casual Users.
- Others who are likely to use the product/system regularly and who's work will get significantly impacted by ir can be referred as Power Users.
- You can also refer to users by their function (e.g. Users from Finance team), Organizational role (e.g. Managers) or even personalizing a need (e.g. Compliance, Audit etc.).
The first part of the Story would be “As a Power User, I want …”, "As a Finance team member, I want...." or "As an Auditor, I want...."
What: User Story Format Element #2
The second part of the standard template states what is desired or needed--the desired outcomes or product features. This is commonly stated as “I want….”
Over time, I've come to believe that "I want" is inaccurate. Sometimes the functionality being described is not something the user role wants at all. For example:
- As IT Security, I want a strong password....
The other way to design this second part is to consider a user as human. In that case, no human 'wants' a strong password. Rather, it should be 'required' or 'need to'
Instead of always being I want, sometimes it can also be I’m required, forced, need to or more.
Why: User Story Format Element #3
- As IT Security, I want a strong password so that the system restricts unauthorized users
- As a Power User, I want lesser number of clicks to complete an action to make it easy to use
Advantages of The 3-Part User Story Template
I think there are four main strengths to the three-part user story template.
1. The Elements Are Presented in the Right Order
I think the elements--who, what, and why--are presented in the right order. Think about any story, not a user story but a movie, a novel, or an anecdote or joke you want to tell a friend. The most important thing in that story is almost always who is doing it. We call that person the protagonist.
When we watch a movie, we need to care about the protagonist before we care about the plot. Only after I know who, do I care about what and why. The standard user story template puts these in that order.
2. The Story Is Told from a First-Person Perspective
We like stories about ourselves. The next best thing to a story about me is a story about you. The least interesting is a story about the guy across town whom I’ve never met.
Stories about I and you and we and she and he are interesting.
Did you know that one of the reasons for the success of the English band, The Beatles’ is the use of a personal pronoun in the name of their songs.
The first British album had pronouns in 8 of 14 song titles (57%). That worked so well their second album had pronouns in 64% of the titles. The Beatles then pushed it to 79% on their third album.
The standard user story template starts with I, the most personal of personal pronouns. Something happens when we have a user story that starts with I. We relate to that story more closely than we would if the same thing were written as a traditional The system shall… statement.
3. Stakeholders Are Immediately Comfortable Filling in the Blanks
Before user stories came along, I loved use cases. But I could never get the stakeholders with whom I worked to love them as much as I did.
Use cases were just too far from how stakeholders thought about their work. Stakeholders don’t think about secondary actors or preconditions or postconditions. And so use cases never worked as well in practice as I thought they should.
I’ve never had that problem with user stories. I can conduct a story-writing workshop with stakeholders simply by writing As a _____, I ______ so that _______ on a whiteboard and telling them we’ve gathered to fill in the blanks as many times as we can.
Stakeholders get it. It’s a natural way of speaking for them.
4. The User Story Structure Helps Product Owners Prioritize
The structure of good user stories actually helps the product owner prioritize. If the product backlog is a jumble of things like:
- Fix exception handing
- Let users make reservations
- Users want to see photos
- Show room size options
... and so on, the product owner has to work harder to understand what the feature is, who benefits from it, and what the value of it is.
Drawbacks of The 3-Part User Story Template
There are two drawbacks to the standard user story template that are worth mentioning.
1. Too Many Stories Are Written as Just “As a user…”
Too often team members fall into a habit of beginning each user story with “As a user…” Sometimes this is the result of lazy thinking and the story writers need to better understand the product’s users before writing so many “as a user…” stories. It's important to have a specific type of user in mind.
But other times it may indicate a system not well suited to user stories. For example, a Financial compliance tracking system has a number of backend processing features which track compliance and only report non-compliances. If a compliance issue was discovered, however, reports would be generated and individuals would be notified. This system benefited from user stories for that small subset of the product’s overall functionality.
In these cases, where a feature exists for a reason but may not be intended for a user, the user stories can be written as a feature requirement.
2. The Template Is Too Often Slavishly Followed
By all means, common sense needs to be a guiding principle for agile teams. When expressing something in the standard user story template doesn’t make sense, don’t use that template. Write it another way, including very possibly just free-form text.
Remember, the intent is not to comply to a template but to deliver value to the client
www.coach-ram.in
Comments
Post a Comment