After coaching many Scrum teams over the past few years, I observed that many new Scrum teams seem to struggle because of low quality User Stories. Even the best teams are likely to fail if they do not have good stories to work from since they define the level of quality and scope for the end product the team will deliver.
I’m sure you have already come across many articles that provide guidelines for what a “good” user story should be; the acronym “I.N.V.E.S.T.” likely rings a bell or two for you. While those guidelines are helpful, they do not necessarily tell you HOW to write a good user story, but offers you insight to determine whether your story meets the standard or not.
To take a more practical approach, let’s try to map out tactically how we go about writing an effective user story.
Tip #1 – Identify the end user (or consumer) of your product/service
More often than you might expect, Product Owners begin writing stories with the solution in mind. They have already thought through what the business users’ needs are and how their problems should be solved, so they write the stories to describe the end product. This is not an ideal approach because the Product Owner is essentially constraining the team’s freedom and limiting their ability to come up with a creative solution. A more effective approach is for the Product Owner to explicitly identify the end user through definition of a “persona”. This term may be familiar to those of you who have written requirements or use cases; in the context of use cases, a “persona” is essentially an “actor”. For this example, we will say that we have a typical banker who uses the banking system to do his work on a daily basis.
By determining a fictional (or real) user, the Product Owner steps into the shoes of that individual to take that person’s perspective, which enables him/her to see the problem in the right light. This is a critical step in the process that many teams fail to do.
Tip #2 – Begin with the end in mind
Some Product Owners, especially ones new to this role, believe that all user stories MUST be written in the form of “As a user….I want to…so that I can….”. While this may be the generally-accepted standard for user stories, my recommendation is that you consider starting with a simpler version of this format. Since you have already identified the user (through the persona), you just need to focus on describing the business process and goal you wish to accomplish. This can take the form of “A system that can print checks automatically at the end of the day”. The key thing to note is that this should describe a business activity (“print checks”). Next, you want to think about the benefit…why do you want to print checks automatically? What’s the value? We want to print checks automatically because we want to reduce manual intervention which saves time and improves accuracy. Ok. So if we put all those elements together, we have the following:
“As a banker, I want the checks to be printed automatically at the end of the day so that I don’t have to do so manually, which will save me time and ensure everything is printed correctly.”
Not so hard after all? Right?
Tip #3 – Avoid tasks as stories
An easy way to spot a poorly-written user story is to look at its basic form. Does it describe a process or solution, or does it indicate action of some sort? If the story starts with an action word (e.g. a verb), it’s a sign that it’s not in the right format and will likely need rework.
Why is this the case, you might ask. Don’t we want to tell the developers/development team exactly what they need to do? Aren’t we doing them a favor by telling them what the task will be?
Not exactly. The purpose of a user story is to describe the desired user experience, their personal interaction with the end system/product, so that the team can build the best possible, most efficient product that meets the user’s needs. The team building the product is the best resource to figure out the specifics of HOW to deliver that solution. The Product Owner must have confidence in the team to do their part.
An example of this scenario might be: “Build an application that can print checks automatically”, or “Design a scheduler to run on a daily basis that can print checks at specific times during the day”.
As you might observe, both of these suboptimal user stories describe the solution in a very narrowly-defined matter, which will likely constrain the team’s thinking and limit their ability to innovate and come up with something that neither the Product Owner nor the banker has thought of.
Ultimately, the most important thing to keep in mind is that you want to leverage the user story as a tool to describe the user experience. Give the team room to think outside the box, to experiment with something new and unfamiliar yet meets the customers’ needs. Give them just enough guidance and they may deliver something extraordinary.