User Stories Well Done

As a Product Owner
I would like to know how to write good User Stories
So that I can provide ideal input to teams for turning requirements into a product increment.

What is an User Story?

An User Story is a brief description of a certain functionality or desired feature from a user’s perspective. In an User Story these pieces of functionality or features must relate to business value. As mentioned User Stories are very brief descriptions and with that become a place holder for conversations between business people and developers When this conversations take place, knowledge is spread across all involved people and a shared understanding is the result. User Stories focus on value to be delivered to an user. They must reasonably sized pieces of work with the preference to the smaller size and still deliver value. With the right size an User Story fits into an iteration and can be turning into a product increment in a short, foreseeable amount of time.
Respecting those characteristics, a User Stories helps track pieces of functionality and the product’s progress.

Who writes User Stories?

In Scrum the product owner is i charge of it, for other methods should be the product responsible accordingly. However, in charge doesn’t necessarily mean also actually writing. Everyone could do it, business analysts, ux designers, programmer, tester or whoever is involved and comes up with an idea that is in line with the product vision. From my experience it is even a good idea to have the team involved in product backlog creation and refinement as good as possible without giving away the product responsibility. As the User Story is a placeholder for conversations and in most cases go through an evolution, it is of less importance who actually writes User Stories. It is more important that it will have a certain quality before it gets turned into a product increment and that conversations about it take place for shared understanding. Note that this is difference when it comes to prioritization of User Stories.

How are good User Stories written?

Well, there are several ways how to get to a good User Story. There is no blueprint or one way how it is always been done. Therefore let’s look at some common approaches that have proven to work well. One set of criteria that helps to write a User Story as well as ensures to end up with an actionable, properly sized and valuable one, is INVEST:

  • I Independent
  • N Negotiable
  • V Valuable
  • E Estimable
  • S Small
  • T Testable

Independent: Do not overlap User Stories with one another and try to avoid dependencies to other User Stories. If dependencies can’t be avoided, try to go with the instinctive order and try to keep dependencies to a minimum. Dependencies and order of user stories must not hinder you prioritizing and changing scope.

Example:

Instead of a User Story with the goal of implementing payment methods, create several User Stories specifying the specific payment methods.

payment methods example
payment methods example

Negotiable: An User Story is negotiable. Based on trust, not formal signed contracts an User Story
is negotiated before it is ready for implementation, meaning it should leave some room for discussion. It is not a strictly defined document with no open questions.

Valuable: All people involved with and working on an User Story should understand it’s value.
Remember that technical debt for example doesn’t add value.

Estimable: As User Stories should be of similar size and be understood by everyone, they are estimable.

Example:

Investigation tasks that are needed in order to remove uncertainty or develop concepts. These activities are usually time boxed and due to lack of knowledge and understanding can’t be estimated.

Small: Try to cut your User Stories as small as possible while still delivering value with it. That makes implementation and tracking easier.
Additionally you shorten feedback loops with the approach of small User Stories. As in size, an User Story’s description should also be very brief and understandable.
It should be possible to turn User Stories into a product increment within days, not weeks or months.

Example:

Try to find the smallest possible unit of work that delivery value. With the payment methods example above, it would look like this:

payment methods credit card
payment methods credit card

Testable: In order to know when a feature or functionality is implemented (done), you need to know how to verify (test). Therefore a set of criteria which determines exactly that, is required. Defining acceptance criteria is best practice in User Story writing. With Acceptance criteria you know exactly when you’re done implementing an User Story and also how to test what you have implemented. Acceptance criteria should be limited to 3-5 per User Story as a good measure of size. Otherwise your User Story might be broken down further.

Slicing an User Story

Always slice vertically in order to create User Stories that deliver value, not implement technical components. Slicing around components or technologies introduces unneccessary dependencies and when a horizontally sliced User Story is done, you still have no working functionality or feature as other User Stories are required to complete the picture. Referring to the INVEST criteria, horizontally slicing User Stories would violate the “I” and the “V”. Therefore all layers (in an IT context such as UX, business logic as well as persistence and potentially furthers) should be covered by a User Story, so that it delivers working functionality and value. Further vertically slicing is precondition to maintain a short feedback cycle.

Reads:

User Stories Applied: For Agile Software Development

 

Leave a Reply

Your email address will not be published. Required fields are marked *