Cet article est également disponible en français

Often within a team, one focus on the immediate effect of a feature or a task: the famous User Story’s “so that…

Note: If you’re not familiar with what a User Story is, you can read my article about it: Differences between epics, stories, themes and features

This element of the User Story template, the “so that…” should express gain the user will get from the feature, and not a sequential sequence of events.

Per example, in this user story:

As a Facebook’s user, I want to be alerted when I have items in my order, so that I can either validate or empty it.

In this example, the “so that” part do not tell the team the value behind the story or what the user will gain from it. We expose here a behavior induced by the US, instead of a profit.

“sequentially I do that, to be able to do that”

A better version of this story would be:

As Facebook’s user, I want to be alerted when I have items in my order, so that I don’t loose an important order I would forget.

In this simplistic version, the US expose to the team the goal of the user, its benefit and it is then easier to find the intended impact, which could be per example:

  • +10% of orders validated amoung not completed ones after 3 hours.

Writing US is one of the most difficult skill to master for a Product Owner, it demands experiences and self-questionning and of course, to be serious about it.

The impact is an essential part of a feature as we talked about in the French video Scrum Life : Product Owner – L’impact du produit – Scrum Life #82.

What do you think?

Photo by Green Chameleon on Unsplash

2 thoughts on “Tips to write BETTER user stories

  1. Bonjour Constantin

    Un grand merci pour cet article.
    C’est clair que l’écriture d’une US pour un PO, ou bien avec l’équipe demande un vrai apprentissage.

    Attention selon moi à l’effet : ah ben c’est ton métier non, et donc décharger de l’équipe de dev une sollicitation pour améliorer l’écriture de chaque US.

    Sinon on retombe dans le même effet d’avant.

    1. Si je comprends bien ton message, en effet, c’est important que bien que l’écriture d’un élément de backlog (et donc d’une US) soit la responsabilité du PO, ce ne devrait pas être une activité solitaire.
      Les parties prenantes et le reste de l’équipe peuvent/doivent participer !
      On a de meilleur résultats quand tout le monde participe.

Leave a Reply

Your email address will not be published. Required fields are marked *