Constantin Guay

— Why do we do that? Asked Miranda.
— Well, it’s in the backlog, isn’t it? Answered Roger.
— Oh…well, yes, ok, let’s unstack the backlog.

When I start with an existing team, I’m often surprised to see that what they call User Stories only express a need but with no clue about the “why”. This reason to have this item in the backlog seems to be optional. Why?

An invitation to a conversation

A User Story is an invitation to a conversation. A conversation between the person who has a need, a problem, and the team who will provide one possible solution to this problem.

A user story, as defined by XP, Mike Cohn, etc. is usually formatted like this:

As…<user>, I want to… <need> so that…

In fact, the formalism of the user story is not very important, but I think a great coach (wearing the role of scrum master or not), should not say that the why is optional. Neither for a user story nor for anything.

This way of writing it is good, but what is important is to know the need, who needs it and, perhaps the most important part: WHY the user needs it.

Engaging, empowering

“The most important part?”

Yes! I do believe so.

“More important that the need itself???”

In fact… yes!

Because as a solution provider, the team, by understanding the goal of a user with its need, could propose another solution, or a slightly different solution that would meet the need of the user.

Remember that an empowered scrum team does not provide “code”, but elegant and resilient solutions, often in the form of a piece of software.

Developers are intelligent people and will often be able to propose more than just what the user wants. But they can do that only if they understand why the user needs the feature.

But it’s obvious!

Sometimes, the Product Owner will not provide the so that… portion of the user story, because well… “it’s obvious why!”

“The user need to login, I don’t have to say why, do I?”

Well… please do, because something as common as a login system should be understood to avoid confusion.

For example, I do think that no user ever asked for a login system. NEVER. I can’t find any value for the user nor can’t find any user asking for a login system. Users usually want “to store their personal information”, or “do not want to enter their shipping address every time they order [and their address to not be public ^^]”.

So, as a Product Owner, if the goal, the objective of the user story is so obvious, it should be very easy to just write it down, shouldn’t it?

And if it’s not so easy to write it down, please take a moment to think about how it is difficult for someone else to understand it. And then, what if their obvious assumption is not the same as yours, or the same as the stakeholder?

Prioritizing and narrowing

Of course, the why (or so that…) is also a good (if not the better) way to prioritize the backlog and narrow (a better way of slicing) a feature.

Note: I’m fan of this concept of narrowing a feature instead of slicing it, I learn it from Allen Holub:

By understanding the why, the whole team can tell which feature they should work on next and why.

They also can provide great and creative way to narrow the feature, for example, if the only why of a login feature is to allow users to continue reading where they were, a first and quick version of this feature could be to only store the user’s position to the browser’s local storage.

It will not fit all users, but will work fine for some of them and can happen sooner than a full and resilient login system.

Sequential

The so that part should not be a sequential event, I alrady wrote about that, you can find the post here.

The why must refer to the benefit from the user’s point of view and the impact on the product and/or the business.

Conclusion

Last, but not least, providing a why, brings some consideration for the team. They don’t just unstack the backlog, they have an objective.

It can play the same role as the sprint objective, to engage people into the product and the team. If you understand french, you can find a dedicated video about the impact on the product on Scrum Life.

Do you always provide a “so that…” on your user stories? If not, can you tell me why?