Stop thinking in tasks, start talking about stories instead

Let me tell you about one of my favorite techniques for helping teams to accomplish their desired outcomes: user stories. If you find your team being slowed down by an enormous backlog of tasks, user stories might be just your thing. They can also help your team to be more:

  1. Customer-obsessed: No more engineering-only tasks. All work is directly connected to customer value.
  2. Continuously refining: Ship something valuable every few days instead of shipping every few months.
  3. Focussed: Clarity on what is the most important piece of work at any time. Stop multitasking between various tasks.
  4. Highly collaborative: Have frequent conversations in a language that all roles can understand, be it product management, content design, design or development. No more tech-jargon.
  5. Autonomous: Allow the developers to make autonomous technical decisions, but to get agreement on everything else.

If this vision is exciting to you, then read on!

The challenges of a distributed team

I’m currently part of a truly distributed team. There is very little time zone overlap and it is basically impossible to get everyone into the same meeting.

Working in an environment like this means that there is very little time to talk face-to-face. Consequently, we have to make the most out of the time we have together by leading focussed discussions, by allowing autonomous decision making and by raising potential blockers early on.

One technique in particular has helped us to master those challenges: applying user stories.

What’s a user story?

Simply put, a user story is an informal feature description, written from a user’s perspective. Now read that again. Most importantly: a user story is not a task!.

Here’s an examples:

As a potential customer, I’d like to search for a particular product.

When you’re beginning to write your first couple of user stories, it can be hard to write them from a user’s perspective. In that case it generally helps to follow a common template like this one:

“As a [role] I can [capability], so that I [receive benefit]. ”

But you don’t have to follow any template if you don’t want to.

Attributes of good user stories

A well-written user story has a couple of attributes:

  • It is independent: it should not depend on any other user story.
  • It is negotiable: it’s not a contract, you should be able to discuss it further.
  • It is valuable: it’s delivering value to your stakeholders.
  • It is estimateable: you can compare its size to any other user story.
  • It is small: it’s possible to ship each story within one sprint.
  • It is testable: it has all the detail necessary for writing automated tests.

If you’re worrying that you won’t be able to remember all these, don’t worry! Conveniently, adding up all the first letters results in the mnemonic INVEST. A colleague of mine has actually suggested an additional attribute of a good story:

  • it is understandable: everybody from every discipline can read the story and understand what part their role plays in making the story a success.

Once you’ve written up your first couple of user stories it is good to go back and check if they have those attributes. If not, try to rewrite them accordingly.

Explore the details through a conversation

Up until now our user stories have been quite simple, they contained no more than a few words. This is how all user stories begin: as simple reminder about a feature that needs to be developed. Alistair Cockburn has phrased this in a different way:

“A user story is a promise for a conversation.”

However, the few words that currently make up our user stories won’t be sufficient to get it delivered. Before we can get started, we need some more information. To get that, we arrange for a conversation with the whole team (e.g. your customers, your developers, your designer, your product manager, your content designers etc).

During that conversation the team will ask and provide lots of questions and answers and will therefore build a shared understanding quickly. Because various stakeholders are involved, all participants have to speak the same language - expect to use little role-specific jargon (e.g. technical speak).

In this way the whole team builds up tacit knowledge, in addition to recording a few notes about what has been discussed.

Here’s an example:

As a potential customer, I’d like to search for a particular product.

  • search should be visible on every page
  • search should be case insensitive
  • results should be ordered by priority
  • if no result is found, potential customers should see a few alternative suggestions

Time to build that feature

At this point, we’re ready to work on the story. Keep in mind though that a user story is a description of a feature and not a TODO list. Therefore, the developers will most likely want to break down the story into a couple of technical tasks associated with the story and distribute those among them.

Furthermore, in an experienced team the meeting notes would be turned into a specification by writing automated acceptance tests (however, our team hasn’t written too many acceptance tests yet).

At the end of the iteration the feature described by the user story should be deployed to actual customers.

Did you notice how user stories associate all work required for a feature with its description and directly tie it to customer value? This is really powerful, because it provides enough context about the task so that the developers can make autonomous decisions (the user story communicates the why instead of just saying what ought to be done).

Planning with user stories

User stories are a great tool for planning in Agile projects, because they allow us to avoid big up-front analysis and instead encourage us to add more detail just-in-time for development.

A project backlog typically begins with an initial set of user stories, each of them containing only a few words that serve as a reminder of a future conversation.

The closer the team gets to implementing a user story, the more detail will be added to that story. Detail is captured via conversations and turned into notes, todo lists, acceptance tests and finally production code.

If a story is too large to be completed within a single iteration, the team can always break it into multiple stories. If it is too small, the stories can be combined. If the team discovers new functionality, it can write new stories. If the team decides to drop something, they throw away the story.

Because of these properties, user stories allow us to continuously refine our products and to focus on what is most important at any one time.

Do you want to learn more?

There’s a lot more to explore about user stories, but this wouldn’t fit the size of a single post. Here’s a rough idea what we haven’t (yet) covered:

I hope that this post has convinced you to try out user stories on your own team. You might find them equally as valuable as us. If you want to learn more, I can recommend the book “User stories applied” by Mike Cohn.