A user story is used to define product or system functionality and the associated benefit of the functionality. In an Agile environment, projects are commonly comprised of a large number of user stories representing various levels of system/product user. This ever growing and prioritized list of user stories is called as product backlog. The user story describes the type of system/product user, what functionality they want, and why they want it. The format of a user story should be:
As a <type of user>, I want to <feature/function> so that <reason/value>
The purpose of the user story is to encourage collaboration among the project team for each defined function of the system or product being developed. Agile project management places emphasis on collaboration rather than formal documentation. Because of this, each user story created by the team represents an opportunity for the team to collaborate, decide which user stories will be worked on in the next iteration, further define the functionality, and accomplish the work.
If the user story does not add value to the finished product then it should be avoided. User story must also include input and feedback from the ultimate customer or product owner. Remember that agile methodology emphasizes collaboration over formal documentation.
Finding the appropriate level of detail for user stories is often a challenge for the team. User stories should be general enough to provide a description of the functionality and the benefit while also allowing for innovation and creativity for developing a solution. They should not be so detailed as to lock the team into only one way of accomplishing the solution.
In the creation of their user stories, many agile practitioners subscribe to the INVEST acronym created by Bill Wake which states that user stories should be:
Independent: User stories should not be sequential or locked into a specific order. The team should be able to develop the user stories in any sequence.
Negotiable: User stories should be flexible and without too much detail. Details will be added later through team collaboration.
Valuable: User stories should add value to the final product.
Estimable: The team must be able to use the user stories to estimate the work.
Small: Large or vague user stories are difficult to estimate. User stories should be able to be designed, built, and tested within a single iteration.
Testable: User story should be able to be tested with some type of acceptance criteria or other test (even if it has not yet been defined)
Acceptance criteria is a crucial component of user stories. As user stories evolve toward iteration planning, the team should collaboratively discuss the acceptance criteria for satisfying each user story. Acceptance criteria are used by the team to understand when the intent of the user story has been met.
Below are examples of user stories which include too much detail, not enough detail, and an appropriate amount of detail.
Too Much Detail:
As an end user, I want the ability to access the product database to generate a stocking report with product names, list price, quantity, unique ID, and brand so that I can periodically update the company’s product list.
Note that the above example goes into listing details about what the report should include. Including these items in the user story may prevent or discourage the team from including other important content in reports that will be built. This level of detail should be defined later during iteration planning discussions to promote collaboration.
Too Short:
As an end user, I want access to the product database so that I can periodically update the company’s product list.
Note that the above example mentions nothing about the ability to generate reports from the product database. Only access to the database is mentioned. By leaving out the key information about generating a report, the team might overlook this important functionality and only grant access to the database when the iteration is performed.
Appropriate Level of Detail:
As an end user, I want to access the product database to generate reports so that I can periodically update the company’s product list.
The above example ensures that when iteration planning begins, the team can plan for both access and report generating while further defining what information the reports will consist of.
User Story with Acceptance Criteria:
Below is an example of a single user story with the acceptance criteria.
User Story:
As an end user, I want to access the product database to generate reports so that I can periodically update the company’s product list in one go.
Acceptance Criteria:
As a <type of user>, I want to <feature/function> so that <reason/value>
The purpose of the user story is to encourage collaboration among the project team for each defined function of the system or product being developed. Agile project management places emphasis on collaboration rather than formal documentation. Because of this, each user story created by the team represents an opportunity for the team to collaborate, decide which user stories will be worked on in the next iteration, further define the functionality, and accomplish the work.
If the user story does not add value to the finished product then it should be avoided. User story must also include input and feedback from the ultimate customer or product owner. Remember that agile methodology emphasizes collaboration over formal documentation.
Finding the appropriate level of detail for user stories is often a challenge for the team. User stories should be general enough to provide a description of the functionality and the benefit while also allowing for innovation and creativity for developing a solution. They should not be so detailed as to lock the team into only one way of accomplishing the solution.
In the creation of their user stories, many agile practitioners subscribe to the INVEST acronym created by Bill Wake which states that user stories should be:
Independent: User stories should not be sequential or locked into a specific order. The team should be able to develop the user stories in any sequence.
Negotiable: User stories should be flexible and without too much detail. Details will be added later through team collaboration.
Valuable: User stories should add value to the final product.
Estimable: The team must be able to use the user stories to estimate the work.
Small: Large or vague user stories are difficult to estimate. User stories should be able to be designed, built, and tested within a single iteration.
Testable: User story should be able to be tested with some type of acceptance criteria or other test (even if it has not yet been defined)
Acceptance criteria is a crucial component of user stories. As user stories evolve toward iteration planning, the team should collaboratively discuss the acceptance criteria for satisfying each user story. Acceptance criteria are used by the team to understand when the intent of the user story has been met.
Below are examples of user stories which include too much detail, not enough detail, and an appropriate amount of detail.
Too Much Detail:
As an end user, I want the ability to access the product database to generate a stocking report with product names, list price, quantity, unique ID, and brand so that I can periodically update the company’s product list.
Note that the above example goes into listing details about what the report should include. Including these items in the user story may prevent or discourage the team from including other important content in reports that will be built. This level of detail should be defined later during iteration planning discussions to promote collaboration.
Too Short:
As an end user, I want access to the product database so that I can periodically update the company’s product list.
Note that the above example mentions nothing about the ability to generate reports from the product database. Only access to the database is mentioned. By leaving out the key information about generating a report, the team might overlook this important functionality and only grant access to the database when the iteration is performed.
Appropriate Level of Detail:
As an end user, I want to access the product database to generate reports so that I can periodically update the company’s product list.
The above example ensures that when iteration planning begins, the team can plan for both access and report generating while further defining what information the reports will consist of.
User Story with Acceptance Criteria:
Below is an example of a single user story with the acceptance criteria.
User Story:
As an end user, I want to access the product database to generate reports so that I can periodically update the company’s product list in one go.
Acceptance Criteria:
- Ability to gain access to product database.
- Ability to generate a report which includes:
- Product name
- List Price
- Quantity
- Unique ID
- Brand
- Ability to use report data to update product list.
- Database is accessible internally but not from outside company network.
- Microsoft Excel report can be generated from database based on query inputs.
No comments:
Post a Comment