Lean process has an exceptional focus on providing value to the customer. Always when an action is considered we ask ourselves "Would the customer be willing to pay for this?" I've often seen when groups are considering an agile transformation they are focusing on faster iterations, but faster iterations of what? An agile team can certainly deliver faster iterations of what the customer doesn't want. Often many poorly run teams do exactly this. For this blog post I would like to consider three elements which I believe can foster the value perspective when creating user stories.
User stories are not a highly documented series of requirements but rather a reminder to collaborate about the topic of the user story—in other words, in agile development (good agile at least), the documentation is secondary to the collaboration. The intent of user stories is to foster collaboration; the perspective is on customer value. If your user stories look more like requirements in disguise, you need to worry less about what specification you are using and more about how to increase collaboration. If, on the other hand, you have a collaborative environment already, user stories will enhance the collaboration more than use cases and traditional requirements can, in which case user stories are a better tool for you.
There are three main problems I see in stories. First is too much information in the description. This leads to a loss of collaboration and a reliance on the old ways of documenting everything. A user story should be thought of as a "talking points", a "to-do list," or a "tickler that a conversation must occur about a topic." The user story is a placeholder for a conversation or series of conversations: it is only through collaboration that a user story works as an agile tool; otherwise it's just a requirement written on an index card.
Too much information in a description can lead to the second problem: missing information in acceptance criteria. Before agreeing to work on a story, the team must understand the acceptance criteria. These are essential for knowing what needs to be done in order to satisfy the user story. Acceptance criteria should be detailed enough to define when the user story is satisfied, yet not so detailed as to quash collaboration. Writing acceptance criteria should not an afterthought – it is a crucial part of a user story.
The third problem is to confuse acceptance criteria and test cases. Both are necessary for a user story. Acceptance criteria answer the question, “How will I know when I’m done with the story?” Test cases answer the questions, “How do I test and what are the test steps?” While both acceptance tests and test cases should be added to the user story via collaboration, only acceptance criteria are required. Test-driven development is often used to flesh out the test cases as the code is written.
Comparing User Stories, Use Cases, and Requirements
The basic difference between user stories and other forms of requirements specification has to do with perspective and intent, both of which affect the level of detail.
Traditional requirements’ perspective is on system operations. They are typically written with the intent of limiting interpretation. They rarely have tests or acceptance as part of the mix – that’s another document – and are often written by someone other than the requirements author. The level of detail can vary, particularly if those writing the requirements are using a hierarchical approach to drill down to successive levels of detail. Traditional requirement focus on what the system should do, not on the user or business workflow.
Use cases have the perspective of the users and their interaction with the system in mind. The use case diagram and associated text are intended to show the capabilities of the user and how these capabilities are met via a system response. Work flows or business flows can be derived from use case diagrams; the text of the use cases shows system and user interaction in a call-and-response format. Use case text typically contains more details than stories and traditional requirements. Test cases can often be written from the use case text, but are not typically part of the use case diagram per se.
Both traditional requirements and use cases are meant to be successively refined into greater detail through detailed analysis and design into. They are both written as the primary communication media for the system capabilities.
User stories focus on customer value. They don’t just assume a looseness of specification; they actually encourage it in order to foster a higher level of collaboration between the stakeholders and the team. A user story is a metaphor for the work being done, not a full description of the work. The actual work being done is fleshed out via collaboration revolving around the user story as system development progresses. As such the level of detail of a user story is ultimately higher than a use case but lower than a traditional requirement. In order to limit scope, user stories have collaboratively developed acceptance criteria which define when the user story meets the stakeholder’s expectations. Test cases are often developed as code (with test driven development) or documented as the code is developed.
Comparison example
Problem Statement
The client has requested the ability to search for health care providers by provider specialty within a doctor selection site.
Sample Requirements Statement:
The provider search screen shall provide the ability to search for providers by provider specialty.
Sample Use Case
The client selects provider search.
The system retrieves a predefined list of provider specialties and populates the specialty list. The system displays the provider search mechanism.
The client selects a provider specialty and initiates the search.
The system retrieves a list of providers that match the provider specialty search. [Alt 1]
The system displays a list of providers that match the search. [Alt 2]
End use case
Alt 1: If there are no matches, the system displays a message indicating that no matches were found. End use case.
Alt 2: If there are more matches than the user can view, the system will provide the capability to display multiple pages.
Sample User story
Title:
Search for providers by provider specialty.
Description:
As a provider search user, I need the ability to search for providers by specialty so that I can more efficiently refer patients to specialists.
Acceptance criteria:
The provider search mechanism has the ability to enter a specialty.
The specialty search will have a list of provider specialties from which to select.
Searching via the provider specialty will return a list of matching specialists or a message indicating that there are no matches.
If there are more results than can fit on one page, the system will provide the capability to view the list in pages or sections.
Conclusion
Are user stories better than other types of requirements specification? It depends. In the end, it’s the individual or team that makes a particular technique work (or fail). If a team is used to an iterative approach, use cases and user stories will be relatively easy to work with. If a team is steeped in waterfall and “big requirements up front (BRUF),” that team likely will bring that style to user stories and end up with traditional requirements that are user stories in name only. Adopting the underlying philosophy (concepts like collaboration and just-in-time requirements) is the key to moving toward more agile specification devices, such as user stories.
User stories are not a highly documented series of requirements but rather a reminder to collaborate about the topic of the user story—in other words, in agile development (good agile at least), the documentation is secondary to the collaboration. The intent of user stories is to foster collaboration; the perspective is on customer value. If your user stories look more like requirements in disguise, you need to worry less about what specification you are using and more about how to increase collaboration. If, on the other hand, you have a collaborative environment already, user stories will enhance the collaboration more than use cases and traditional requirements can, in which case user stories are a better tool for you.
There are three main problems I see in stories. First is too much information in the description. This leads to a loss of collaboration and a reliance on the old ways of documenting everything. A user story should be thought of as a "talking points", a "to-do list," or a "tickler that a conversation must occur about a topic." The user story is a placeholder for a conversation or series of conversations: it is only through collaboration that a user story works as an agile tool; otherwise it's just a requirement written on an index card.
Too much information in a description can lead to the second problem: missing information in acceptance criteria. Before agreeing to work on a story, the team must understand the acceptance criteria. These are essential for knowing what needs to be done in order to satisfy the user story. Acceptance criteria should be detailed enough to define when the user story is satisfied, yet not so detailed as to quash collaboration. Writing acceptance criteria should not an afterthought – it is a crucial part of a user story.
The third problem is to confuse acceptance criteria and test cases. Both are necessary for a user story. Acceptance criteria answer the question, “How will I know when I’m done with the story?” Test cases answer the questions, “How do I test and what are the test steps?” While both acceptance tests and test cases should be added to the user story via collaboration, only acceptance criteria are required. Test-driven development is often used to flesh out the test cases as the code is written.
Comparing User Stories, Use Cases, and Requirements
The basic difference between user stories and other forms of requirements specification has to do with perspective and intent, both of which affect the level of detail.
Traditional requirements’ perspective is on system operations. They are typically written with the intent of limiting interpretation. They rarely have tests or acceptance as part of the mix – that’s another document – and are often written by someone other than the requirements author. The level of detail can vary, particularly if those writing the requirements are using a hierarchical approach to drill down to successive levels of detail. Traditional requirement focus on what the system should do, not on the user or business workflow.
Use cases have the perspective of the users and their interaction with the system in mind. The use case diagram and associated text are intended to show the capabilities of the user and how these capabilities are met via a system response. Work flows or business flows can be derived from use case diagrams; the text of the use cases shows system and user interaction in a call-and-response format. Use case text typically contains more details than stories and traditional requirements. Test cases can often be written from the use case text, but are not typically part of the use case diagram per se.
Both traditional requirements and use cases are meant to be successively refined into greater detail through detailed analysis and design into. They are both written as the primary communication media for the system capabilities.
User stories focus on customer value. They don’t just assume a looseness of specification; they actually encourage it in order to foster a higher level of collaboration between the stakeholders and the team. A user story is a metaphor for the work being done, not a full description of the work. The actual work being done is fleshed out via collaboration revolving around the user story as system development progresses. As such the level of detail of a user story is ultimately higher than a use case but lower than a traditional requirement. In order to limit scope, user stories have collaboratively developed acceptance criteria which define when the user story meets the stakeholder’s expectations. Test cases are often developed as code (with test driven development) or documented as the code is developed.
Comparison example
Problem Statement
The client has requested the ability to search for health care providers by provider specialty within a doctor selection site.
Sample Requirements Statement:
The provider search screen shall provide the ability to search for providers by provider specialty.
Sample Use Case
The client selects provider search.
The system retrieves a predefined list of provider specialties and populates the specialty list. The system displays the provider search mechanism.
The client selects a provider specialty and initiates the search.
The system retrieves a list of providers that match the provider specialty search. [Alt 1]
The system displays a list of providers that match the search. [Alt 2]
End use case
Alt 1: If there are no matches, the system displays a message indicating that no matches were found. End use case.
Alt 2: If there are more matches than the user can view, the system will provide the capability to display multiple pages.
Sample User story
Title:
Search for providers by provider specialty.
Description:
As a provider search user, I need the ability to search for providers by specialty so that I can more efficiently refer patients to specialists.
Acceptance criteria:
The provider search mechanism has the ability to enter a specialty.
The specialty search will have a list of provider specialties from which to select.
Searching via the provider specialty will return a list of matching specialists or a message indicating that there are no matches.
If there are more results than can fit on one page, the system will provide the capability to view the list in pages or sections.
Conclusion
Are user stories better than other types of requirements specification? It depends. In the end, it’s the individual or team that makes a particular technique work (or fail). If a team is used to an iterative approach, use cases and user stories will be relatively easy to work with. If a team is steeped in waterfall and “big requirements up front (BRUF),” that team likely will bring that style to user stories and end up with traditional requirements that are user stories in name only. Adopting the underlying philosophy (concepts like collaboration and just-in-time requirements) is the key to moving toward more agile specification devices, such as user stories.
Nice points. I prefer somewhat more information in the user story statement following the template "As a WHO, I need to WHAT because WHY." You have only stated the WHAT. Knowing the target audience and their motivation can alter your design space considerably.
ReplyDeleteThis was really good. The point about conflating acceptance criteria with test cases was great, needs to be said more.
ReplyDeleteNice. While I buy your 3rd problem description re confusing acceptance criteria and test cases, you can still write the acceptance criteria in the form of a test case - an acceptance test case. This then begs the question of what's the difference between a "test case" and an "acceptance test case". If you mean TDD type functional test cases, then the test is typically to ensure that the way you intended your code to behave is actually the way it behaves.
ReplyDeleteContrast this with an acceptance test case, which is typically to ensure that an intended requirement of the user story is actually met (regardless of how the requirement is implemented). I think this distinction is important, but YMMV according to your definition of "test case".
Thought provoking blog, thanks Patrick. I've quoted it as the start of my blog post:
ReplyDeleteCommunication: User stories vs. Requirements