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. 

Titles
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.

Description
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).

Sample
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

What outcome you may expect from a sprint review?

The meeting is held in the end of each sprint, for the team to have completed work reviewed by stakeholders. The team members present and demonstrate the product increments, to ensure the expectations are meet.

Benefits for stakeholders product owners

  • Review the increments
  • Up to date with progress
  • Validate increments towards expectations
  • Data for prioritizing

Benefit for team members

  • Individuals as well as team feel accountability for quality
  • Validate that expectations are meet
  • Interdisciplinary / cross functional skills are developed
  • Team commitment and spirit is nurtured
  • Team and team members are motivated

The motivational factors deserve some further discussion, as I believe only few consider the major motivation benefit achieved. When a team member are allowed to demonstrate his / her work, it will give a sensation of succeeding in what they do. By seeing stake holders caring about the work completed, team members will feel valued and have a sensation of recognition for the work well done.

Why sprints?

Why do we want to do thing in sprints, and what’s the benefits doing so?

Many of us use sprints, without being aware or taking advantage of the benefits. Many are even just using sprints as content holders for activities, and for lining up work to their teams.

Assuming that a sprint should have a defined sprint outcome, and that it should be potentially shippable. The stories in a sprint are planned and there is a commitment to the content, both by the team and the rest of the organization. Start and end date are of course fixed…

When there is a time boxed and committed scope of stories, we actually limit our variability by the length of the time box / sprint. The team will then be allowed to work with less interruptions and context switching for the length of a sprint, meaning a more efficient flow and predictable delivery. Shorter sprints allow more variability and change in priority, to ensure we adjust and allow changes to meet business and customer values.

Sprints have a start and finish dates, and finishing / completing the sprint allow us to feel good about reaching our goal. Most of us are motivated by reaching goals, and reaching goals as a team create a great team spirit.

Delivering potential shippable software often, are also known to increase quality.

The predictable delivery achieved in sprints that are potential shippable, create great trust with the stakeholders and organization.

The standup question “What did I do yesterday”

The standup question “What did I do yesterday”, is just awkward to me. If you attended yesterday, you should know what i did yesterday. I get the point with the question and the idea behind it, and in some cases it make sense. But then again if it feels silly to the team and do not make sense, I believe that it will harm more than it do good and absolutely it will not motivate to continue with such meetings. I’ll replace this question, and motivate to tell about yesterday if there is anything to learn or give a meaning to tell about.