Boost Team Performance by Writing Proper User Stories

Poor user stories slow teams down and make them unpredictable. Proper user stories make teams more reliable. Clarity about what’s to be done and why vastly improves the chances of it getting done in time. Small, independent user stories also allow the business to change course quickly. This article explains how to tell if your user stories are good enough, what should and shouldn’t be in one, and what the first definition of “ready” should be.

1- Write user stories from a user perspective

Approach software development from a user point of view by imagining what it would be like to be the end-user of the application. You’ll be doing everything for them. Use a standard user story template to describes the stakeholder, his wants, and gains. A typical template includes the phrases: “As a …, I want…, so that…” — use it! For example, “As a tourist, I want a car so that I can drive to the hotel.” However, “As a ranger, I want a car so that I can drive through the woods.” Both result in a car being built, but who it’s for and why they need it results in a completely different car. There are a million ways to build things. Stating who for (as a…) and why (so that…) in advance helps the team prioritize the product backlog and build the right things. Aside from that, it makes the difference between good enough and great.

2- Add specific, clear acceptance criteria

Steve Job got it right when he said, “It doesn’t make sense to hire smart people and tell them what to do. Instead, hire smart people to tell you what to do.” Exploit the skills of the team. Don’t tell the team how to do things. Acceptance criteria are the boundaries of a solution. Leave enough space for the team to do what they’re best at — creating the best possible solution. When writing acceptance criteria, ask yourself the following questions: Is it really an acceptance criterion? Or is it a task? Or is it forcing the team to do things a particular way?

3- Make sure the product is shippable when the user story is done

Stay away from technical user stories. A product needs to be shippable at all times. The key to a shippable product is to add small bits of business value to it regularly. That’s why technical user stories are evil. Feature requests or epics often get split up into technical stories. Usually, that requires teams to pick up these stories in a particular order. It becomes a waterfall. Once the team gets started on the first story, there’s no way back. And when it’s completed, there’s no new feature. Sometimes it’s even worse — the product isn’t shippable anymore because it’s under construction. The product owner loses control that way. She’ll only have two options. She can either wait until all the stories have been completed and get the full blown version of that feature or stop half-way through the building process, roll back all the changes and end up with nothing but a waste of time.

4- Create small user stories

Big stories are difficult to estimate and communicate. What’s the scope? They start with many tasks, and then, during the sprint, more and more tasks appear. They’re full of minor details. Some details are built quickly, some take forever, and others turn out not to be a detail at all. Learn to recognize scope creep; he’s not our friend. Describing three weeks work for an entire team on a single Jira ticket is no small feat. As a rule of thumb, the team should be able to complete a story within a single sprint. Identify the smallest possible chunks of business value. Those should be the stories.

5- Create user stories that can be picked up autonomously

When stories depend on other stories, they must be picked up in a particular order. Try to create as few dependencies as possible. That allows the teams to pick them up in any order the business wants.

6- This is document is your first definition of ready

Test user stories with a definition of ready before the team commits to the sprint backlog. Don’t have a definition of ready? Start with your definition of ready version 0.1 by checking it against the following questions:

  • Is this user story written from a user perspective?
  • Are the acceptance criteria specific and clear?
  • Is the product shippable after this story is completed?
  • Is this story small enough?
  • Can this story be picked up autonomously?

Don’t pick up any story if the answer to any of these questions is “no.” Fix that in the refinement. Note that a definition of ready is not a static document. Review it in the retrospective, and add things to it!