Writing a good user story which is just enough to understand the context and objectives of the “customer need” and trigger further conversation among the team and users is always one of the biggest challenges for agile teams. As the human language is a way of expression and every human has their own unique way of expressing things, there are many ways to describe customer and user needs. A level of standardization align with the best agile practices would help to build a good baseline for a common understanding between team members as well as between the team and stakeholders.
I am a big believer of continuous learning and training to achieve a mature and successfully agile team. Not all team members have got a similar level of experience, therefore, continues experience sharing and training should be also part of the the agile ceremonies.
The following INVEST – User Stories presentation was a part of the one of the continues sharing and learning ceremony that I shared with the team I worked with.
What is a User Story?
A user story is a short, simple and natural language description of one or more features. User Stories are written from the perspective of the person who desires a new capability to achieve something through a product or service.
What is the differences between User Stories and Enabler Stories?
User stories deliver functionality directly to the end user.
Enabler stories bring visibility to the work items needed to support exploration, architecture, infrastructure, and compliance. *
(*) © Scaled Agile, Inc.
The format of a User Story
User stories are written in a value-centric format:
“As a <user>, I want <goal> so that <reason>”
By using this format, the teams are guided to understand who is using the solution, what they want to do with it, and why they want to do it.
What makes a good User Story?
Independent
Negotiable
Valuable
Estimable
Small
Testable
(*) Origins
•2003: the INVEST checklist for quickly evaluating user stories originates in an article by Bill Wake.
•2004: the INVEST acronym is among the techniques recommended in Mike Cohn’s “User Stories applied“, which discusses it at length in Chapter 2.
Independent
Stories should be as independent as possible. Why is this important?
•It allows true prioritization
•Dependencies make estimation harder
•Dependencies cause waiting times, therefore waste
Negotiable
A User Story is not a contract of what needs to be implement in the solution. It’s an invitation to a conversation. The story captures the essence of what is wanted and why. The actual solution is delivered as a result of collaborative negotiation between the User (or user proxy like the Product Owner) and the team.
•When a story is in the backlog, its context is negotiable
•Conversations and dialogue between team members are the key
•When the story is pulled in to the development it is no longer negotiable, any changes to it will be considered a new story to be added to the backlog
Valuable
A story should provide value to the customer or the user. If a user cannot think of a value statement, then perhaps we should de-prioritize the story or maybe the work is unnecessary anyway.
•The story should have a purpose that gives value to the users
•The ‘so that…’ part of the story demonstrates that value
Estimable
The team should be able to estimate a story. It should be written in such a way that the team can understand it and have an idea of how to implement it as well as size of the work required to deliver the story.
Barriers to estimation could be:
•Lack of domain knowledge
•Lack of technical knowledge
•The story is just too big
Small
Stories should be small enough to estimate and prioritize and big enough to demonstrate the value to the user.
“Obviously stories are small chunks of work, but how small should they be? The answer depends on the team and the methodology being used. I teach agile and suggest two week iterations which allow for user stories to average 3-4 days of work – TOTAL! This includes all work to get the story to a “done” state. Also remember not to goldplate user stories. You should do the simplest thing that works – then stop!” *
(*) Rob Hartman, https://agileforall.com/new-to-agile-invest-in-good-user-stories/
Testable
A User Story should have clear acceptance criteria that the story can be tested against in order to be marked as “done”.
•Avoid vague and qualitative acceptance criteria (e.g. “a User must find solution easy to use”)
To download the Invest – User Stories presentation please click <HERE>