You see it all the time, people slipping into task oriented backlog items instead of user story oriented items. It looks something like this:
Create this functionality because I need it to do that.
Certainly, functionality might be necessary, but we have no context for whom it is for or what the value might be. We have to connect the work to the user and to the value. Without doing so we risk conducting work that will be a waste of time.
So how do we avoid this habit of task oriented thinking? As developers we are wired that way; we think in functions. Some invaluable tools can help discipline us to contextualize our work in a different way.
Keep your eye on the goal
Writing a user story is at once deceptively simple and insurmountably hard. How do you articulate in a concise statement a well sized, negotiable piece of work that has value? The first step is to stop focusing on the work and focus on the value.
At the end of the day, any user story must present value. If it does not, then the resultant work will be a waste of time. However, repeatedly I see user stories that leave off this crucial element. The story is, “as a user I want the application to do this.” The common “so that” is completely left off. On the surface this merely results in a vague sense of implied value. If we look deeper we see that the user story itself was not constructed, or birthed, through the process of valuation with the stakeholders. There was no negotiation of value between the product owner and the stakeholders. We have a fundamental breakdown in the communication between the developer and the end user.
You have to understand that the “so that” isn’t an optional part of the user story. In fact, that question of value is the very heart of the story. The task or behavior is in support of the value and if we miss that we miss the whole point of Agile.
We often discuss the end-user of an application, a theoretical, all-encompassing individual. This imaginary end-user is simultaneously a new user and a power-user and everywhere in between. They represent all the various facets of application use. This may be an extreme assessment, but often true in degrees.
Rather than thinking in such abstract terms, put some meat on the bones. Use concrete terms for end-users. For instance, rather than stating a user story of:
As a driver, I want a car that can take me from point A to B so that I can get around town…
Be more specific with your user types like:
As a teenager who just got his license, I want a car to take me from point A to B as fast as possible while making me look good so my friends will think I am the coolest cat around.
As you can see, just specifying the user more specifically inherently reveals more about the value of the work to that user. A teenager doesn’t just want to get around town. Moreover, we now understand how to fulfill the teenager’s request better.
Rather than creating these specific users on a case by case basis, take the time to create persona cards for the most common, stereotypical users of your application. The card should list:
- Picture and Name
- Details about the person, what they like / hate, etc.
- Their goals
The persona cards should be clear enough that developers can picture the user of the user story. This connection with the user is vital to the delivery of value.
Generally most work can be categorized into some broad areas of value, here are a few:
- Cost Reduction
- Revenue Generation
- Quality Improvement
- Risk Reduction
Depending on the application, these might look entirely different. The point is that you can group work into areas of value focus. You should do this early and on every user story.
Not only does this help align your user stories to their value proposition, but it helps in the eventually prioritization and planning of the work. If you have all the user stories color coded to their value category, then you are going to readily see where you are spending your development efforts. This can assist decision making.
Talk it out
Stumped how to construct the user story for the work? Talk it out loud. Not only will this help create the user story, but often you will mention the scenarios for acceptance criteria in the effort of articulating the work.