A user story describes how the user will use the software in just a few sentences. User stories can be used to represent a new feature, an enhancement to an existing feature, a technical task (like a nonfunctional requirement), or a defect unearthed during testing.
As a < type of user >, I want < some goal > so that < some action or reason or benefit > happens.
It uses the “role-feature-reason” template and the focus is on Who (the user), What (the desired goal), and Why (the end result).
e.g. As a credit card holder, I want to view my statement (or account) balance, so that I can pay the balance due
INVEST – Independent, Negotiable, Valuable, Estimable, Small & Testable
The guidelines for writing a good user story can be summed up with the acronym INVEST:
I – Independent: user story should be able to be described apart from one another.
N – Negotiable: all of the features in a product are the product of negotiation.
V – Valuable: there’s no reason to spend time writing a card that isn’t valuable to your users.
E – Estimable: each user story needs to convey a feature that the team can assign as size or effort number to.
S – Small: user story should describe independent interactions, not huge categories of functionality.
T- Testable: being able to test each user story is what makes it such an effective feedback loop for Scrum teams.
SMART – Specific, Measurable, Achievable, Relevant & Time-bound
Another acronym to denote attributes of a user story is SMART.
S – Specific – User story that is specific helps to convey its purpose to the team and helps to keep it independent.
M – Measurable – User story should be estimable (in terms of story points, for example) and measurable against the definition of done.
A – Achievable – User story should be unambiguous and the team should be able to achieve the doneness criteria within the timeboxed iteration. If the story is not clear, then the team can either split it into manageable parts or seek more clarification from the Product Owner to hash out the finer details of the stories.
R – Relevant – User story should add relevant value to the customer and contribute, incrementally, to the overall objective or goal of the project. Since time and effort are expended, it is very essential that the ROI is maximized while implementing each story.
T – Time-bound – User Story should be such that they can be reasonably accommodated in the timebox that the team mutually agrees. If the timebox expires, the team discards the unfinished work and does not count it toward the velocity attained by the team in that specific iteration.
3Cs – Card, Conversation & Confirmation
User stories need to be confirmed with the 3C guidelines below, suggested by Ron Jeffries:
Card: User stories are traditionally written on index cards or sticky notes, in short form. User narratives further explain these cards. Thus the main intention is to describe the user story in the short form to allow a common understanding of the user need among all stakeholders.
Conversation: User stories shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
Confirmation: Acceptance tests confirm that the story was delivered correctly.
DEEP – Detailed Enough, Emergent, Estimated Relatively & Prioritized Ordered
Another well-known acronym is DEEP
Detailed Enough—acceptance criteria to get started.
Emergent—The Product Backlog is never “complete”; it is refined over time.
Estimated Relatively—sized in terms of effort.
Prioritized Ordered—by value, risk, cost, dependencies, etc.
User Story – Gathering Techniques
Interviews: one or more team members schedule a formal meeting with a sponsor, customer representative, or a subject-matter expert, ask them a series of open-ended questions to identify their needs and desires of the system, and document their responses.
Surveys and questionnaires: Already have a list of requirements, need more information about them or their respective demand for a large user base set is via a survey or questionnaire.
Voice of Customer: One of the varieties of surveys is the Voice of Customer, which is used to determine the customers’ needs ranked in order of relative priorities and urgencies.
User role modeling and Persona: This technique stresses the importance to identify and consider the variety of users that will be interacting or benefitting from the system.
Agile Prototyping and wireframes: Agile prototyping is a technique that is used by the development team to seek clarification on the requirements gathered.
Greenfield technique: In this technique, the users are asked to imagine an environment where there are no constraints, boundaries, or existing structures. This stimulates original thinking about the product requirements, fosters creativity, and frees the mind from unnecessary clutter.
Group creativity techniques: Techniques like Brainstorming, Nominal group technique, Delphi Technique, Idea/mind mapping, Affinity diagram, Multi-criteria decision analysis
Focus groups and facilitated story-writing workshops: These are forums for interactive discussions held between qualified, cross-functional stakeholders and subject-matter experts.
Job shadowing: In this technique, the team member ‘shadows’ and observes how a real-life user uses the system or interacts with the product and its environment.
Group decision-making techniques: Once the ideas are collected, decisions are made by the following:
- Unanimity – everyone agrees to a decision and a consensus is reached.
- Majority – more than 50% of the participants agree to a decision.
- Plurality – largest block decides even if the majority is not reached.
- Dictatorship – one individual makes the decision on behalf of the group (e.g., when sufficient time is not available to reach consensus).
Innovation Games for User Story Gathering
Buy a feature: The game starts with a list of features and their estimated cost to deliver them. Customers are provided with imaginary cash and asked the ‘buy’ the features that matter to them the most. The features are heavily priced compared to the cash with the customers and this leads to discussions and negotiations on the value of a feature. The outcome of this technique is a prioritized list of features that the customers are willing to pay for.
Product box: In this game, the customer pretends that he is selling the product at the marketplace to another skeptical customer. He pulls features out of a product box and tries to impress the customer by telling him why it is worth buying it. The goal of this technique is to shortlist the most impressive and valuable features that the customer admires.
Prune the product tree: This game starts by drawing a large tree that represents the core functionality and branches of various widths to represent components and features. Users are asked to come up with new features, write them on ‘leaflike’ cards and paste them on the tree or the branches, with the supporting features being closer to the trunk than others. As more and more cards get posted, the tree takes a shape that denotes where the majority of the functionality or improvement is desired. This results in an evolving version of the product vision.
20/20 vision: The aim of this game is to discover which feature is most important to which stakeholder. The analogy is with an optometrist who tries out lenses of different power to narrow down to the one that suits the eye most. Similarly, the facilitator of this game writes the features on cards and shows them to the stakeholders one card at a time and asks them to rank them in order of importance. If the card has lower importance it is placed lower in the pile and if the card denotes an important feature it is placed high up. The game ends when the pile of cards is exhausted and all cards have been arranged in order of importance.
Remember the future: In this game, the project stakeholders are told to imagine a situation in the future where the product has been delivered and it has been several months or years that they have been using the same. They are then asked to think of the product characteristics or features that caused the most meaningful difference to their lives or provided the maximum benefit to them. This helps to understand the stakeholder’s definition of success.
Me and my shadow: In this exercise, the team members literally sit next to the user and watch what they do and how. The sessions can often be recorded with a camera to watch how their eyes move and the actions they take to get their job done. At times the users are asked open-ended questions to justify their actions or read their minds. This technique helps to unearth hidden needs.
Sailboat: The game starts with drawing a sailboat on a whiteboard. The boat is expected to move real fast, but unfortunately, there are a few anchors that hold it back. The users are explained that the boat represents the system and asked to identify the risks and bad features that act as anchors and impede the usability of the system or its performance. Similarly, the users are also asked to identify positive opportunities or ‘wind’ that could propel the sailboat forward. These ideas could be scribbled on sticky notes and posted on the whiteboard, as shown in Figure 6-14. With this in hand, the project team is able to put the risks, pain points and impediments on the watch list and proactively manage them better.
Bang-for the buck: This technique is used by the team and the customer together to rank the value and the estimated cost of a feature.
Start your day: In this game, the participants are asked to describe their monthly, weekly, and daily activities relative to the usage of the product.
The apprentice: In this game, one of the team members uses the existing product in a way the actual user is expected to use it in real life. The real-life situation helps the team member create empathy with the customer and discover potential problems that need to be addressed to improve the usability of the product. An example could be a car mechanic driving a car to see what it feels like.
My worst nightmare: In this game, the user is asked to imagine the worst-case scenarios that might be hidden and share with the group.
Force field analysis: The force field technique helps to analyze the forces that either drive or hinder a change in the system. For more details Click Here.
Acceptance Criteria
Acceptance criteria complement the narrative: The criteria enrich the story, make it testable, and ensure that the story can be demoed or released to the users and other stakeholders. As a rule of thumb, I like to use three to five acceptance criteria for detailed stories.
The acceptance criteria for the credit card story could be:
- Display statement balance upon authentication. Say for example $160
- Display total balance. For example $560. Here the balance due from the current period is $560 and past balance due is $2000.
- Show Minimum payment due. For example $40
- Show Payment due date. For example May 16th of the current month
- Show error message if service not responding or timeout. For example ‘Sorry, something went wrong with the service. Please try again.’
Best Practices for User Story
- Consider user proxies if the customer is not available.
- Slice the cake vertically – Instead of splitting stories along technical components.
- Try to achieve closed Stories – Instead of being an ongoing activity, a story should be such that it achieves a specific and meaningful goal.
- Use the simplest tool, Write it in simple language, Defer user interface details as long as possible
Reference
https://www.mountaingoatsoftware.com/
Book: Ace the PMI-ACP® exam
User story estimation: Planning Poker – Agile Estimation Method