User stories in scrum
User stories are used to gather customer requirements. User story is a common term for requirements small enough to be brought into a sprint and broken into tasks. User stories are one action of value that a user will achieve, such as “As a shopper, I want to be able to scan a product bar code with my phone so that I can compare and find the lowest price of the same product at multiple stores.”Multiple user stories go into every sprint, and each are highest priority at that time. On average, you may have six to ten user stories per sprint. Therefore, at the end of each sprint, if the development team concentrates on completing one requirement at a time (a process called swarming), you always have something to show for your work.
You might want to use 3x5 index cards to write user stories. With a Card → Conversation → Confirmation model, you get rich requirement clarity before development starts. User stories aren’t the only way to describe what needs to be done, but we’ve found them to be incredibly effective.
Don’t use technical jargon in your user stories. You’re writing them with the user in mind. Keep them direct, customer-focused, and simple.
In the Card → Conversation → Confirmation model, the product owner uses the 3x5 card as a reminder of the requirement — a reminder that a conversation must take place to refine and clarify it. This model enables the immensely valuable activity of conversing with development team members and answering their questions, supported by an explicit description of what success looks like on the back of the card.
Sometimes, it’s easiest to work with personas: fictional characters who are amalgams of the target qualities of your clients. A persona might be a 35-year-old single male, professionally employed, who lives in Portland, Oregon, and is looking for his future significant other. Use a persona to ensure that your project meets your target customer’s needs.A user story description is simple yet focused, clearly describing the user, the action, and the benefit. On each card, enter the following lines:
- An ID number that’s the same as in the product backlog and that’s assigned by the product owner when she accepts an item into the product backlog
Keep your product ID numbers simple. You don’t need to be able to track every item back to its more generic origin; you just need to give it a numerical name, like 123, not like 10.8.A.14. You minimize the amount of work you do by ridding your project of time-wasters so that you can focus on the important things.
- A shorthand title
- A description of the user
- What the user wants to accomplish
- The reason the user wants to accomplish the task
Each user story is written in the first-person point of view (“When I do this, I get this”). First person puts the author in the shoes of the user or customer.
The person who writes the user story gives it to the product owner to share with the development team. Often, the stakeholder also participates in the conversation phase, sitting down with the product owner and development team to go over every card. This act of direct communication is vital to a thorough understanding of the tasks necessary to achieve the result desired. As a result, communication is clearer and mistakes are fewer, and project quality and delivery speed increase.Further refinement for successful scrum
Development team effort determines whether a requirement needs to be broken down further to progress to the product roadmap, into the release plan, or into the sprint. Especially at the beginning, as you find out how to apply user stories within your scrum framework, you may find that the ones you write are too big to fit into a sprint.Although most user stories have multiple steps, some are bigger than practical and can (and should) be broken into more granular requirements. This process is part of the discovery process and part of the benefit of using user stories.
You may find additional requirements that need to be placed in the product backlog during the user-story elaboration discussion. Excellent! These discoveries help you gain deeper understanding of what the customer and/or user need.