Conversation Patterns: A User Story Template Revisited

This article is part of my work on Conversation Patterns for Software Professionals

---

This is well known user story template:

As a [role]
I want [feature]
so that [benefit]

But I noticed that because of this template teams focus mostly on features. What is wrong with that? However, discovering the right features is the goal of user stories, but at the same time a benefit part is neglected.

Consider following (anti)stories:

• As a User I want to login, so that I use a system
• As a User I want to print report, so that I can do my job
• As a User I want to click RMB, so that I choose wanted option from the context menu

These are examples of stories where a benefit part was not clarified enough. Again, what is a big deal?

In general a benefit is a need and another type of a need is a problem to be solved. So, a role wants a feature because one requires a benefit or problem solution. This is natural feature - business need relation.

A feature is a way to satisfy business need by the software functionality. Having need clearly defined a team and PO are able to discover set of features satisfying business need and choose the best one.

But using a given user story template we start a conversation from a feature without talking about a business need first.

Then we want to fill a template so it is possible to put some general benefit instead of, you know, the "real" one.

My solution is: use a slightly different user story template:


In order to [benefit/problem to be solved]
I want [feature]
Being a [role]


---

UPDATED@10/03/2014
Upon further study I decided to redesign the given template as follows:

In order to avoid [problem to be solved]/In order to achieve [expected benefit]
As a [role]
I want [feature]

So now we have two US templates for each of stakeholder's need favour.

---

This template helps to focus on business need first. When the one is clearly defined you may start discovering possible features to satisfy the need.