Background:
The concept of the “User Story” originated in Extreme Programming in the late 90’s and has become the fundamental building block of product planning and delivery across various forms Agile, Scrum, and XP adopters. Learning to write effective User Stories is an art that takes time and must adapt to the team and product for which the stories are written.
Basics:
The basic structure of the user story defines the user’s role, necessary action, and expected outcome:
“As a [role] I want to [interaction] so that [outcome].”
Here is an easy example of the traditional “post-it note” User Story:
“As an online shopper, I want to share my purchase on Facebook so that my friends see it on Timeline.”
Each of these are important to the developer:
- Outcome – the result expected by the user is the most important element of the user story. The focus on user outcome was the major drive in Scrum and XP to adopt the User Stories – software developers wanted to know what value for the end user was being created. If an outcome is not testable by new user (“hallway” testing) with minimal ambiguity of expected outcome, we have failed the user! By aligning the User Story around a valuable outcome expected by the target user, the development team (including testers) and the Product Owner can easily align around what is being built, why it is being built, and whether or not it creates value. As highest criteria for business value creation, it is the outcome that drives the Product Owner’s prioritization of the Product Backlog.
- Interaction – the outcome lets everyone align around the goal of what is developed, while the interaction necessarily defines how the user does it. In new product development, while the Product Owner works with the stakeholders to define the most valuable outcomes for the target users, the Well-Formed Team works cross-functionally to define how the user creates the valued outcome. This is where the “ideal state” of 3-minds-and-a-whiteboard ought to be able to define user experience, technical implementation, and testing approach with a few conversations.
- Role – role can define two things quickly and easily. 1) The relationship the user has to the product (admin, owner, end user). 2) The business context that helps define the Interaction design. In the above example the “online shopper” in the story is loaded with important information that can be quickly assimilated: the user has made a purchase, so they are on the last screen in the check-out workflow, they are not an admin or owner, they have likely registered in the past and are now authenticated due to the necessity of payment system security. A wealth of business context is alluded to in a few words. In a narrowly-focused product, this might be left off completely because the role does not change across stories.
I.N.V.E.S.T. Criteria
As I described in Incremental AND Iterative Product Delivery the effectiveness of a User Story is driven by its “nimbleness” and user focus. Once an architectural runway and design paradigm are established, new vertical slices should be easy to add with minimal refactoring. Vertical product slices follow the I.N.V.E.S.T. criteria:
- Independent, end-to-end, “shippable” increments of the emergent whole. The slice could be delivered fully tested without any other product increment and create value for the user or owner.
- Negotiable, in planning and expectations with users and stakeholders, allowing delayed incorporation of enhancements or, if a major pivot becomes necessary, easily removed from the product roadmap (without previous over-engineering, over-planning, or over-documentation).
- Valuable to the user or owner, likely in a way that is sufficiently noticeable that it is monetizeable.
- Estimable by the delivery team because the User Story does not generalize or hide uncertainty. An inestimable story is often an Epic. It is either complex enough to warrant a technical spike or compounds enough feature work that it should be broken into independent, smaller, user stories.
- Small enough to be estimated by a team, with certainty, and deliverable fully-tested within a single sprint.
- Testable by virtually any team member because the expected outcome is qualitatively or quantitatively noticeable (as part of its being valueable) to the target user.
The I.N.V.E.S.T. method for user stories ensures that planning and development occur just-in-time so that the emergent product can regularly evolve in response to changing stakeholder demands. More importantly, in the fast-paced markets in which digital product programs compete today, incremental delivery maximizes the freedom to release the Minimum Viable Product and pivot in a new direction based on real-time feedback from users.
Conversation Starter, Conversation Reminder
In Scrum and XP circles a User Story is succinctly defined as “A reminder of a conversation.” It should be simple in focus but rich in context as a reminder for conversations that have been had and conversations that need to take place. Note that this definition contains nothing I wrote above! This was done intentionally as it aligns with the tenets of the agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Lengthy documentation about “business requirements” and “product specifications” created several unhealthy habits in Waterfall organizations – the “requirements” often had nothing to do with making the life of the user better, the specifications often were no longer relevant by the time an engineer needed to build the product, and the multiple decision-makers made conversations impossible! A user story is conversation starter and a conversation reminder because it is intended to encourage interaction, collaboration, responsiveness, and tangible progress.
If you are going old-school and using actual cards or post-its, the User Story (role, action, outcome) should easily fit on the front. This is enough for a Product Owner to prioritize the stories and remind him and the team that a conversation needs to take place. During Sprint Planning, if interaction or technical implementation decisions are made, these can easily fit bullet-point-style on the back a reminder of what was already discussed.
This method works great at company like Spotify, where static feature teams can become subject-matter experts and the business context is understood by the cross-functional, self-contained team members. If you are writing stories for Rapid Application Development, especially as a contractor to another firm – more details captured in a tool like JIRA may be appropriate, and “just-enough” additional documentation can be useful until the new product achieves the normal team velocity.
Looking for more insights? Feel free to ask questions in the comments, attend a Scrum User Group Event or connect with me directly.
Connect With Me:
Keener Strategy 
One thought on “User Stories 101”