Well-Written Scrum Stories
Well-written stories are easy to understand by all developers and other team members, such as QA or documentation. They allow the Scrum team to accurately estimate the effort needed to implement the work according to the team’s definition of done (the exit criteria to determine whether a story is complete).
A Scrum story has the following basic conditions:
- The story description relates to a user persona, such as administrator, and either describes a business value or addresses technical debt.
- The story acceptance criteria are measurable and testable.
2 Story Descriptions
A good user story description should identify:
- The role of the user persona in the system.
- The need expressed by the user persona.
- The benefit to all stakeholders, such as developers, users, and others, of meeting the stated requirement.
Typically, this is expressed:
"As a <role>, I want <goal or need>, so that <benefit>."
2.1 Examples of Good Descriptions
- Description: As a developer, I want to publish the current state of my application to an update set, so that I can deploy it to a production system.
- Description: As a customer, I want to receive notifications when an incident is commented, so that I am updated on the status.
- Description: As a change manager, I want to enable the assessment of risk for any given change by establishing a list of questions with multiple choice answers.
2.2 Example of Bad Description
- Description: Notifications are sent when incidents are created.
This description is poor because:
- The description does not state who or what is sending the notifications, not in what form the notification takes, such as email.
- The description does not include any benefit information, so the business value is not clear.
It could be better written as:
- Description: As an incident creator, I want email notifications to be sent to a predefined set of interested parties when I create an incident, so that they can be informed when an incident affecting them is created.
3 Story Acceptance Criteria
Acceptance criteria define the boundaries of a user story, and are used to confirm when the software is working as intended, which means the story is completed. They are an essential part of the definition of done for that story.
Good acceptance criteria should include the following, where relevant:
- Usability: Be sure to include measures of usability in the acceptance criteria. Indicate how to answer the question: Is it easy to use? The key is to identify the right measurements and make sure each is quantifiable.
- Functionality: Identify specific user tasks, business processes, or functions that must be in place at the end of the project. A functional requirement might be: The user can choose from multiple sizes.
- Error handling: Enumerate error cases and how each should be handled. For example, if a user performs the steps in the wrong order, how will the software handle it?
- Performance: Test system performance from the perspective of an individual user. For example: Is the UI responsive?
- Stress tests: Describe how the system responds when it is under stress because there are many users, transactions, or queries. Acceptance criteria should define acceptable thresholds for stress testing. For example: Does the system respond within a 250 millisecond threshold when 100 users submit queries simultaneously?
3.1 Example of Good Acceptance Criteria
Description: As a customer, I want to order and pay for the book via a secure web-based form, so that my credit card information is safe.
- All mandatory fields must be completed before a customer can submit a form.
- Information from the form is stored in the customer orders database.
- Payment can be made via Amex, Master Card, or Visa credit card.
- The system shall accurately calculate and apply sales tax.
- The system shall accurately calculate and apply shipping charges.
- The customer shall be able to verify the accuracy of the order.
- An acknowledgment email is sent to the customer submitting the form.
- Protection against spam is working.
3.2 Example of Bad Acceptance Criteria
Description: As a customer, I want to receive notifications when an incident is commented, so that I am updated on the status.
Acceptance Criteria: The appropriate people are notified when incidents are commented.
The acceptance criteria are poor because they do not give enough detail to test; for example, it's not clear who the appropriate people are.
The acceptance criteria could be better written as:
- As an ESS user, create an incident.
- Select Notify interested parties.
- Save the incident.
- Log in as an interested party.
- Check that you have received an email for the logged incident.