The user story covers three points:
• The user's role
• The goal the user is trying to achieve
• Why the user wants to achieve it
It takes the following form:
As a I want to so that I can .
As an example:
As a customer, I want to be able to compare two products so that I can easily understand the differences in feature and price.
User stories are an effective way to communicate requirements that tie into personas by specifying a role, and to express the desired capability and the justification for adding the capability. The story provides the context for the product designers and engineers to develop creative solutions to meet th user's need.
INVEST
Bill Wake in Extreme Programming Explored (2001) introduces six attributes of a good story that can easily be remembered with the acronym INVEST.
• Independent—Avoid dependencies between stories. Each story should stand alone so they can be re-prioritized in the Product Backlog at any time and not impact either the order or any other stories. You also want to keep the stories granular, so the highest priority elements of a feature get implemented first. This is also described as separating the feature from the embellishments.
• Negotiable—Stories are a starting point for a conversation with development. They are not a command. Many product managers have learned that the proper way to write requirements is to use the word "shall" to indicate unambiguously that the product must perform the described function.
• Valuable—Always demonstrate why the story is worth implementing. If you are struggling to identify why the story is valuable, go back and spend more time investigating the story with your customers. You may have missed an important aspect of the story, or the story may not be worth the development effort and ongoing maintenance.
• Estimable—The story should be small enough and contain enough detail that the development team can estimate the effort. Epics should still be used as placeholders in the Product Backlog to capture important ideas and signal intent. But as the epic moves towards the top of the backlog, it will need to be split into stories so the team can estimate the work.
• Small—A story should represent between a half-day and two weeks of work and should definitely be small enough to fit into an iteration.
• Testable—Acceptance criteria for the story should be able to be tested to ensure the user's need has been met.
Acceptance Testing
Acceptance tests are written on the back of the user story card. The tests are used to let the developer know when the requirement has been met and to confirm that the product works from the user's perspective.
A story is not complete and cannot be assigned to an iteration without acceptance criteria. Acceptance testing is the responsibility of the whole team. As such,acceptance tests can be added at anytime by any team member. The product manager, however, should look to facilitate this process by sitting down with engineering and QA to brainstorm the acceptance criteria.
Acceptance tests capture many of the functional elements and boundary cases of the feature. By communicating functionality via tests, it makes it easy to for the engineer to know when development on the feature is done and for QA to validate that the feature works.
You may also hear these tests referred to as "satisfaction criteria" This refers to the high-level test cases that the feature should fulfill prior to the product manager, developer, and QA person brainstorming the full set of acceptance tests and boundary cases.
Acceptance testing is not a bug hunt in the traditional sense. The unit testing is in place to prevent bugs from accumulating in the code in the first place. Acceptance testing really focuses on whether the requirement was met. Other forms of testing such as stress or nonsensical input testing may also be warranted and would be conducted as an additional step.
Non-Functional Requirements
User stories are best suited for functional requirements. Non-functional requirements typically seem forced when put into the user story format. A story
to communicate that the product should run in multiple browsers would be written:
As a customer, I'd like to be able to use the browser of my choice so I don't have to download a new browser.
It would just be clearer to write what is intended:
The application shall run on Internet Explorer 7.x and higher, Firefox 3.x and higher, and Safari 4.x and higher.
Constraints and performance measurements can also be particularly challenging, because to be accepted they have to wait until the end of not just the iteration, but of the full release. In the example of multi-browser compatibility, all user interface requirements are dependent on this constraint.
Constraint Cards
Mike Cohn, in User Stories Applied (2004, 178–179) lists seven constraints with examples:
1. Performance: Ninety percent of product searches will return results in
less than three seconds.
2. Accuracy: The software will dynamically generate and adjust reorder
points to provide in stock levels of 98 percent for all standard products
while maintaining less than fourteen days' inventory on hand for 95 percent
of all standard products.
3. Portability: The software shall be designed to be ported to Android.
4. Reusability: The graphics rendering engine will be reusable by our other applications.
5. Maintainability: Automated unit tests must be written for all new code and be run after each build.
6. Interoperability: All documents shall be stored in XML.
7. Capacity: The data mart must be able to store one hundred and eighty million transactions (three million per month for five years) and support the real-time analytics tools.
System Quality Cards
Another technique for handling non-functional requirements is the system quality card. As functional requirements focus on "what the system will do," system qualities describe "how well the system will do it."
Below is a real-life example of a system quality requirement for a navigation system that was forced into the user story template.
As a Driver, I would like a faster load time for navigation, so I don't have to wait for it to load.
In addition to sounding unnatural, the story is neither testable nor estimable. It just does not work well as a user story. Instead, a system quality card should be used.
A system quality card has six areas:
1. Name: The name of the quality (must be unique)
2. Scale: What will be measured, including the units of measure such as seconds
3. Meter: How the measurement will be conducted
4. Target: The desired level of performance
5. Constraint: The point at which the performance is unacceptable
6. Benchmark: The current level of performance
Use of user stories is just one way to capture requirements in Agile development. But by no means is it the only way. Many teams succeed just fine by writing straightforward requirement statements and even producing more traditional requirements documents.
Regardless of documentation format, the goal is to maximize conversation about each requirement within the team and have a workable method to prioritize, re-prioritize, and separate features into small enough increments to fit into iterations.
Reference: Agile Excellence™ for Product Managers A Guide to Creating Winning Products with Agile Development Teams By Greg Cohen
• The user's role
• The goal the user is trying to achieve
• Why the user wants to achieve it
It takes the following form:
As a
As an example:
As a customer, I want to be able to compare two products so that I can easily understand the differences in feature and price.
User stories are an effective way to communicate requirements that tie into personas by specifying a role, and to express the desired capability and the justification for adding the capability. The story provides the context for the product designers and engineers to develop creative solutions to meet th user's need.
INVEST
Bill Wake in Extreme Programming Explored (2001) introduces six attributes of a good story that can easily be remembered with the acronym INVEST.
• Independent—Avoid dependencies between stories. Each story should stand alone so they can be re-prioritized in the Product Backlog at any time and not impact either the order or any other stories. You also want to keep the stories granular, so the highest priority elements of a feature get implemented first. This is also described as separating the feature from the embellishments.
• Negotiable—Stories are a starting point for a conversation with development. They are not a command. Many product managers have learned that the proper way to write requirements is to use the word "shall" to indicate unambiguously that the product must perform the described function.
• Valuable—Always demonstrate why the story is worth implementing. If you are struggling to identify why the story is valuable, go back and spend more time investigating the story with your customers. You may have missed an important aspect of the story, or the story may not be worth the development effort and ongoing maintenance.
• Estimable—The story should be small enough and contain enough detail that the development team can estimate the effort. Epics should still be used as placeholders in the Product Backlog to capture important ideas and signal intent. But as the epic moves towards the top of the backlog, it will need to be split into stories so the team can estimate the work.
• Small—A story should represent between a half-day and two weeks of work and should definitely be small enough to fit into an iteration.
• Testable—Acceptance criteria for the story should be able to be tested to ensure the user's need has been met.
Acceptance Testing
Acceptance tests are written on the back of the user story card. The tests are used to let the developer know when the requirement has been met and to confirm that the product works from the user's perspective.
A story is not complete and cannot be assigned to an iteration without acceptance criteria. Acceptance testing is the responsibility of the whole team. As such,acceptance tests can be added at anytime by any team member. The product manager, however, should look to facilitate this process by sitting down with engineering and QA to brainstorm the acceptance criteria.
Acceptance tests capture many of the functional elements and boundary cases of the feature. By communicating functionality via tests, it makes it easy to for the engineer to know when development on the feature is done and for QA to validate that the feature works.
You may also hear these tests referred to as "satisfaction criteria" This refers to the high-level test cases that the feature should fulfill prior to the product manager, developer, and QA person brainstorming the full set of acceptance tests and boundary cases.
Acceptance testing is not a bug hunt in the traditional sense. The unit testing is in place to prevent bugs from accumulating in the code in the first place. Acceptance testing really focuses on whether the requirement was met. Other forms of testing such as stress or nonsensical input testing may also be warranted and would be conducted as an additional step.
Non-Functional Requirements
User stories are best suited for functional requirements. Non-functional requirements typically seem forced when put into the user story format. A story
to communicate that the product should run in multiple browsers would be written:
As a customer, I'd like to be able to use the browser of my choice so I don't have to download a new browser.
It would just be clearer to write what is intended:
The application shall run on Internet Explorer 7.x and higher, Firefox 3.x and higher, and Safari 4.x and higher.
Constraints and performance measurements can also be particularly challenging, because to be accepted they have to wait until the end of not just the iteration, but of the full release. In the example of multi-browser compatibility, all user interface requirements are dependent on this constraint.
Constraint Cards
Mike Cohn, in User Stories Applied (2004, 178–179) lists seven constraints with examples:
1. Performance: Ninety percent of product searches will return results in
less than three seconds.
2. Accuracy: The software will dynamically generate and adjust reorder
points to provide in stock levels of 98 percent for all standard products
while maintaining less than fourteen days' inventory on hand for 95 percent
of all standard products.
3. Portability: The software shall be designed to be ported to Android.
4. Reusability: The graphics rendering engine will be reusable by our other applications.
5. Maintainability: Automated unit tests must be written for all new code and be run after each build.
6. Interoperability: All documents shall be stored in XML.
7. Capacity: The data mart must be able to store one hundred and eighty million transactions (three million per month for five years) and support the real-time analytics tools.
System Quality Cards
Another technique for handling non-functional requirements is the system quality card. As functional requirements focus on "what the system will do," system qualities describe "how well the system will do it."
Below is a real-life example of a system quality requirement for a navigation system that was forced into the user story template.
As a Driver, I would like a faster load time for navigation, so I don't have to wait for it to load.
In addition to sounding unnatural, the story is neither testable nor estimable. It just does not work well as a user story. Instead, a system quality card should be used.
A system quality card has six areas:
1. Name: The name of the quality (must be unique)
2. Scale: What will be measured, including the units of measure such as seconds
3. Meter: How the measurement will be conducted
4. Target: The desired level of performance
5. Constraint: The point at which the performance is unacceptable
6. Benchmark: The current level of performance
Use of user stories is just one way to capture requirements in Agile development. But by no means is it the only way. Many teams succeed just fine by writing straightforward requirement statements and even producing more traditional requirements documents.
Regardless of documentation format, the goal is to maximize conversation about each requirement within the team and have a workable method to prioritize, re-prioritize, and separate features into small enough increments to fit into iterations.
Reference: Agile Excellence™ for Product Managers A Guide to Creating Winning Products with Agile Development Teams By Greg Cohen
No comments:
Post a Comment