Writing effective user stories and work items

I believe with some basic principals in mind, everyone can write better user stories and work items.

So often i find the user stories and work items being written to vague and general, in a way that the allow for the scope to change or widen as we go.  It may not describe the expectations at all, or communicate the outcome expected of the work item. I do not mean the scope should never change, because it will and it certainly should. If the scope change it should result in changing the user story to represent the new or changed scope, or another user story which cover the new aspects. 

The title should describe the user story and its scope clearly, in a way that you can know when it is completed. Meaning it should not be vague and wide, even if the description is clear and with a defined scope.

Many stakeholders only read titles and when they are vague, they will for sure make their own assumptions and have expectations that exceed the scope. You can of course pin them for not reading the description, but their experience is already compromised. Even with good titles this will be a challenge, but their expectations are much closer to what they get and will by the title see if there is a need for clarification.

Imagine what expectations you create when a story have the title “Translate to Norwegian” and status is completed, some would assume that now everything is translated. What a drawback when the stakeholder find that only the captions was translated, when he infract expected captions, metadata and content to be in Norwegian. A better title would then have been “Translate captions into Norwegian”, or “Translate captions into Norwegian for …”

Another thing that happen when the title is vague, is that the scope tend to change a lot as we go. Because of the title and expectations created by the title alone, project managers as well as the stake holders will continue to change and add expectations which widen the scope. This way you never know when it will be completed or when expectations will be met. These changes should maybe take place, but as changes or new stories and not as mutating stories.

The description should first of all communicate the outcome we want to achieve, by telling who, what and why will get you fare. 
Many (including my self) use the format “As a … I want …, so that ….”, but why should you use it?

This format help you communicate who will be affected, what want to achieve and way they want so. The simple sentence help ensure that everyone involved works towards the same outcome, it allow to work proactive and ask the right questions.

Now assume that you write the description as a script for how it should be implement, without defining your preferred outcome. The team would most likely be working reactive, and limit them self to the script as robots. They have no way to challange you, or proactively look for and suggest a better way. Nor will they be able to test that your script actually will result in the outcome, or expectations stakeholders are looking for.

After defining the outcome I add a section for defining the expectations, not just the obvious but any which are mentioned or answer to a question. The expectations could be a bullet list explaining some constraints, opinions, preferred solutions, script step by step or whatever is needed. I like to update this section whenever we clarify a new question, or receive new information (with the scope in mind of course).

As a user of Ford C Max I would like my car to open the rear door automatically when swiping my foot below the door,
so that I do not need to put my bags down to open cause they may get dirty.

  • Sensor for foot swipe is expected to cover the whole area between the tires
  • Door should stop in case it meets any resistance, so that damage is avoided to the door or people behind it
  • Should make a sound to alert, before it opens
  • Should be a delay after making the sound, so that the user may take a step back before the door opens

Tags: , , , ,

2 responses to “Writing effective user stories and work items”

  1. PM Hut (@pmhut) says :

    Hi Asbjorn,

    How do you prioritize and track dependencies between your user stories? And how do you handle issues when you discover that two user stories are dependent on each other (usually these issues when the user stories are being executed) – e.g. user story A relies on user story B to get accomplished, while user story B relies on user story A to get accomplished.

    Thanks for sharing!

    • bjaanes says :


      your question inspires me to make this the topic of a new blog post, but I’ll try to give a simple answer to your question 🙂

      I like to use epics for relating stories, also give them a scope and size to make dependencies as transparent as possible. Working with short sprints and a queue system, it is easier to queue stories that needs to be executed a particular order.

      The team work close on maintaining the queues and planning the sprints, breaking down the stories and to clarifying them.

      By using a pull system, the team members will pull stories that are ready and story B would be started first because A is not yet ready.

      When on the other hand an unexpected or unplanned dependency issues arise, this is immediately raised as an blocking issue (visual on story boards) and could result in re-plannising the queue. This would be a subject for daily stand ups or board walks, so that concequences and resolution is discussed as the issue is raised.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: