Working with different organizations over the years, soliciting requirements and properly articulating them are critical and one of the primary concerns I hear from project managers, business leaders and developers. In agile, scrum and Kanban, User Stories are the primary communication method of capturing requirements, their business value and criteria for acceptance.
Development team members crave details. In order to do their jobs properly, most feel that a surplus of information is always best, allowing them to understand the “big picture”. Business people are focused on features and when they will be delivered and don’t need as many details. Product Owners are caught in the middle and need to deliver to both parties.
I have developed the ACTION-able definition of a user story to set clear goals for a “good” story, clarify the amount of detail and write a User Story that communicates just enough information for the team and customers to be happy.
I use the acronym A-C-T-I-O-N to create acceptance criteria for a well-written User Story. Using these acceptance criteria for the completion of any user story you write, will improve the quality of your communication, estimation and the overall team understanding of your user stories. If you find that any of these criteria are not satisfied, then the story should be refined or redefined.
Acceptance driven
Concise
Testable
Independent
One action
Natural
Acceptance Driven
Is your story focused on business acceptance criteria? User Stories are a description of functionality, the individual or role that will perform the story and a brief overview of the business value. The details of those actions and outcomes must be quantified under the acceptance criteria. For example, if I were defining the story “As a customer, I would like a shortened checkout process, so that I can complete my order in half the time.” The acceptance criteria should include details such as desired sales lift this more efficient process should take, or how this change could reduce the amount of orders that are never completed. The criteria should provide the team with quantitative details that can be measured and define when the User Story is complete.
Concise
The User Story should be defined in a single well formed sentence. If your statement is a run-on sentence or you are tempted to use multiple statements, consider breaking it down in to smaller User Stories. To continue our e-commerce example, a lengthy story may be: “As a customer, I would like to see an order confirmation after my order is processed. I should be able to print this confirmation so that I can keep a record.” This story is focused on a seemingly single user story of completing and order and printing a record, but it can be made more concise as two individual stories.
“As a customer, I would like to see an order confirmation after my order is processed so that I may review the details.”
“As a customer, I would like to print my order confirmation so that I may keep it for my records.”
By defining them individually, we gain a better understanding of the user’s motives and needs. Common signals that your story statement is too lengthy are multiple sentences and the usage of the word “and”, as well as other conjunctions.
Testable
Acceptance criteria should be testable through empiric, automated means. Automated testing is important to overall system quality and allows the development team to more easily practice Test Driven Development, ensuring “Quality Up Front”.
For example, “Order processing should be faster”, is not a testable acceptance criteria. “Order processing should complete in under 500ms” if precise and testable.
The product owner should be able to verify each item in the acceptance criteria either through both manual testing and access to automated test reports.
Independent
A user story should stand on its own. Meaning that completing it does not depend on another story. A story needs to encompass a single unit of work a user may take, but it does not have to be working beyond itself. Avoid the temptation to let implementation details cloud the dependencies of a story as well. For example, lets take a look at a common system function of Creating, Reading, Updating, and Deleting (CRUD) a record in a database. For each operation, each requires the creation of the database to store information. While this implementation detail only needs to be done once, each story should assume that this work needs to be done. This becomes extremely important for planning and estimating. When planning releases or iterations of development, we do not want to have to worry about inter-story dependencies that could affect which story comes first.
One Action
Similar to being Concise, take care to focus on a single fluid action a user may perform. A story can be concisely expressed in a single sentence involving a one role, action and business reasoning, but additional actions can creep into the acceptance criteria and during implementation.
For example, lets imagine a user story for sending email: “As a user I would like to send a short message to another user to update them on project details.” The acceptance criteria may include:
- The user must enter a valid email address
- The user must enter a message of at least 1 character
- The user should be able to select an email address from their address book. <=== BINGO
Here is an additional action masquerading as acceptance criteria. Similar types of features, while valuable and user friendly commonly emerge during development as well. Focus on developing functionality in a single linear path. When new ideas and requirements emerge, capture them in a new story on the backlog.
Natural
User Stories should always be defined according to natural user interactions. If you find yourself describing a system to system interaction or the story is not something a user would need to do with the software as a matter of business, you should re-evaluate the story. It may need to be broken down, or could be a solution in search of a problem. Also, beware of implementation details or bugs masquerading as user stories. While these items can certainly be described as a user story, I believe they need to be treated differently.
I hope you find this technique valuable to apply to your own User Story writing and evaluation. Connect with me on Twitter @tmichaelrogers and let me know about your experiences writing user stories and what tools you find useful.