User story pitfalls

A 4 minute read written by Orville March 3, 2016

Image of a stick figure falling into a pit.

We like to write user stories to specify project requirements. Unfortunately, from time to time we fall victim to a few pitfalls that make stories less effective. Here are a few pitfalls to watch out for in your next project.

It’s more fun when you share

Conflicting schedules and competing project priorities can make it tempting to write stories on your own. Don’t do it! This approach has come back to haunt us time and time again. When you try writing user stories alone, you lose out on perspective. Having your team around creates opportunities to exchange ideas, allowing you to examine problems from a variety of angles.

When working on stories as a team, I have found that it can be challenging to get the conversation started. It’s a good idea to craft some story titles individually and prepare questions or discussion points for each story to get people talking. The key is to work together to verify the stories and determine if the story needs to be split.

Even when you are not the primary contributor to a story, everyone benefits from just being in the room. Valuable contextual knowledge is gained during these group discussions, which helps build up a team’s collective knowledge. This in turn can be really helpful when the team needs to provide support for members that are away sick or on vacation.

Really… who cuts the cake sideways?

We have based stories on function from time to time, which means we’ve created stories specifically around a content strategy, design, UX or development discipline. We tend to fall into this groove because we’ve worked using a linear method (rather than iterative) for many years and in many cases, our clients also expect work to be delivered this way.

Basing stories on function is not necessarily a pitfall, as long as everyone’s expectations are aligned. The problem with “slicing the cake horizontally” is that we end up creating silos within the team, which can lead to confusion when things are handed off between functional areas. When you base stories on function, it’s difficult to effectively work as a team since you are working to deliver one layer of work, which will likely produce an incomplete story.

"Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer". "We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers."

Bill Wake

By slicing the cake vertically, you better utilize your entire team across multiple disciplines to deliver a functional feature - as opposed to delivering just a wireframe or a design. This approach lends itself to more teamwork, less confusion from handing off between functional areas, and the end result is a functional feature.

A chart illustrating the layers of the cake from GUI at the top, to database at the bottom

Everyone cheats, so should you

There are so many great user story writing resources out there, and I’m guilty of not taking advantage of them. Here are a few must-have cheat sheets that you need in your story writing toolkit:

INVEST criteria cheatsheet

INVEST is a common acronym to remind teams what characteristics make up a good user story. According to Bill Wake, well-formed stories meet the following criteria:

  • Independent - a story can be picked up and developed in any sequence, in other words, there shouldn’t be any dependencies on other stories.
  • Negotiable - a story should be flexible and provide guidelines without dictating how things need to be done.
  • Valuable - the story must be valuable to the customer; this often takes the form of a functional feature the customer can do something with.
  • Estimatable - an estimable story is one that can be understood enough that the team can use it for planning and scheduling.
  • Small - smaller stories are easier to estimate and plan. You should be able to design, code, test within a sprint or iteration.
  • Testable - a story should have acceptance criteria. If a story isn’t testable, it’s likely not clear enough.

Learn more about INVEST from Bill Wake’s article. You can also download this simple cheat sheet.

Story splitting cheatsheets

Writing stories so that they are small enough that they can be estimated and used for planning can be difficult. Here are a few cheat sheets that can help you split (or break down) stories into more useful sizes.

The Introduction to User Stories and Splitting Stories series from Agile Learning Labs discusses ways to split stories by examining conjunctions, connectors, generic words and more. Check out their quick reference guide (pdf).

Christiaan Verwijs also has a great article called 8 useful strategies for splitting large user stories. I like this article because Christiaan provides questions to ask for each strategy, which makes for a great reference during discussions. Be sure to download her story splitting cheatsheet (pdf) as well!

And if those cheat sheets aren’t enough, you can also check out this handy story splitting flowchart (pdf) from Agile For All.

What pitfalls have you come across?

Do you have any pitfall stories or other cheat sheets you’d like to share? Shoot me an email, better yet come over for a coffee, we have great coffee.