Stories
Stories provide a light-weight approach to managing requirements for a system. A story captures a short statement of function on an index card and/or in a tool. The details are figured out in future conversations between the team and the product owner or customers. This approach facilitates just in time requirements gathering, analysis and design by the following activities:
Story Form
As a <role>
I can <activity>
so that <business value>
Role - represents who is performing the action. It should be a single person, not a department. It may be a system if that is what is initiating the activity.
Activity – represents the action to be performed by the system.
Business Value – represents the value to the business. Why is this story important?
Story Decomposition
A story generally starts out as an “epic” – a large, vague concept. This type of story is good to capture and place in the product backlog, but can not be implemented within a sprint. In order to prepare the work for sprints, a team must break down an epic story into smaller stories through successive vertical slices of the story. This is primarily done as part of release planning, but will continue through to sprint planning when the team may discover that there is more to the story than originally considered. It also may require further decomposition during sprint planning to fit it into the sprint.
Story Acceptance
In addition to the statement of the story in story form, additional notes and acceptance criteria can be kept with a story. Many discussions about a story between the team and customers should take place between the inception of a story and its final implementation, both before and during the sprint it is worked on. The alternate flows in the activity, acceptance boundaries and other clarifications identified in these discussions should be noted with the story. Many of these notes should be turned into acceptance test cases when the story is implemented.
INVEST Guidelines
- Slicing stories down in release planning,
- Tasking stories out in sprint planning
- Specifying acceptance test criteria for stories early in development
Story Form
I can <activity>
so that <business value>
Role - represents who is performing the action. It should be a single person, not a department. It may be a system if that is what is initiating the activity.
Activity – represents the action to be performed by the system.
Business Value – represents the value to the business. Why is this story important?
Story Decomposition
A story generally starts out as an “epic” – a large, vague concept. This type of story is good to capture and place in the product backlog, but can not be implemented within a sprint. In order to prepare the work for sprints, a team must break down an epic story into smaller stories through successive vertical slices of the story. This is primarily done as part of release planning, but will continue through to sprint planning when the team may discover that there is more to the story than originally considered. It also may require further decomposition during sprint planning to fit it into the sprint.
Story Acceptance
In addition to the statement of the story in story form, additional notes and acceptance criteria can be kept with a story. Many discussions about a story between the team and customers should take place between the inception of a story and its final implementation, both before and during the sprint it is worked on. The alternate flows in the activity, acceptance boundaries and other clarifications identified in these discussions should be noted with the story. Many of these notes should be turned into acceptance test cases when the story is implemented.
INVEST Guidelines
- Independent – Stories should be independent from other stories. This allows for them to be completed in any order in the product backlog. In practice, this is one of the most difficult guidelines and works against the Small guideline. It is better to have dependent small stories than to have independent large stories. If stories have dependencies, note them in the story so that the estimate reflects that dependency.
- Negotiable – Stories that allow for flexibility in implementation promote the creative process. Stories are typically general statements that do not indicate all of the specific details and alternate flows within the function. Allow this negotiation to happen during the conversation with the team and the product owner.
- Valuable – Stories should provide value to the customer. Even architectural stories should state the business value they are providing.
- Estimatable – Stories ready for a sprint are estimatable in story points. If a story cannot be compared in size to another story, it is too big. If a story is over 13 story points, it is too big and should be decomposed further.
- Sized appropriate – Stories that are small provide more clarity in definition and completion. A sprint should include multiple stories. Smaller stories are more efficiently processed by a team.
- Testable – Stories need to be testable. Open-ended or vaguely defined stories that cannot define specific acceptance criteria are to be avoided. Examples include “The system shall respond quickly to the user.” Or “The system shall support hundreds of concurrent users.” Attempt to specify the actual times, volumes and other criteria when defining stories.
