SCRUM User Story Life Cycle
•Download as PPTX, PDF•
7 likes•12,452 views
User stories go through three phases in their lifecycle: 1. Creation - when a new idea is captured by the product owner and expressed as a user story in the product backlog. Acceptance criteria and estimates are added. 2. Sizing - the team assigns story points to size the effort required. The story is then prioritized for sprints. 3. Implementation - the story is developed during a sprint, demonstrated, and accepted or returned to the backlog if criteria are not met.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to SCRUM User Story Life Cycle
Similar to SCRUM User Story Life Cycle (20)
Recently uploaded
Recently uploaded (20)
SCRUM User Story Life Cycle
- 1. * What is a User Story? User Story Lifecycle Phase I User Story Lifecycle Phase II User Story Lifecycle Phase III
- 2. * • An agile expression of a requirement focusing on value As a <role> I want <action> So that <business value> • Provides structure • Promote discussion and collaboration • Light-weight approach using simple language understood by all participants in a project <role> : actor performing the action <action> : what will happen (not how) <business value> : what upon completion this user story contributes to the overall goal
- 3. * Story Lifecycle I - Creation -> Ready for Estimation • An idea comes from Stakeholders in the form of : • Change request • New functionality • A Product Owner captures a business request and creates a user story • The user story is added to the backlog • The user story is groomed by the Product Owner with assistance from the Sprint Team • The user story is broken down and acceptance criteria is created through discussion • Prioritization is started • The user story is now ready for sizing Backlog Grooming • Breakdown • Acceptance criteria • Sprint team contributions Idea Idea is captured and a story is created
- 4. * Estimation • Acceptance criteria • Sprint team contributions • Story point assignment Story Lifecycle II – Sizing (Agile Estimation) • The user story is groomed and right sized for an iteration • The sprint team sizes each story on the list, using relative sizing called a Story Point • A story point (size) is assigned to the user story through triangulation to like stories • The user story is available for more precise prioritization into sprints • The user story is ready for sprinting (can be accepted by the team into a sprint iteration)
- 5. * Story Lifecycle III – During the sprint iteration • The user story is accepted into the sprint iteration by the sprint team during planning • The sprint team decides the various tasks to meet the acceptance criteria specified • The sprint team completes the tasks required to meet the definition of done for tasks and stories • The user story is demonstrated at the end of the sprint iteration to the Product Owner during the review • The Product Owner accepts or rejects the story based on if it meets the acceptance criteria • The user story is considered complete and closed or dropped and returned to the backlog for a future iteration Tasks are completed Sprint iteration Returned to backlog to be reprioritized Returned to backlog and closed
- 6. * For more Agile information please visit our websites * www.torak.com * www.agiletestingframework.com *
Editor's Notes
- Notes: A user story is a way to express a requirement User stories are created for each perceived business value within a project and added to a sprint team’s product backlog User stories can be prioritized They are light-weight and easily understood by all participants within a project The details emerge through conversations and discussions They clearly represent the need without implying the solution
- Notes: A user story can be initiated by anyone within an organization A user story can start with an idea, a discovered need or a change to existing functionality within a system The Product Owner owns the product backlog for one or many projects, it’s the Product Owner who translates the requirement into a user story Once the Product Owner has a user story, its added to the backlog and prioritized As a user story becomes a priority, it will be taken into the backlog grooming to be groomed by the Product Owner and Sprint Team A user story can be groomed multiple times by different participants The Product Owner will revise the user story until its in a stable state and ready for Sprint team members or the whole team to participate The Sprint team member(s) or whole team will discuss the user story with the Product Owner and refine the user story until its ready for estimation This includes filling in some details through conversation, adding acceptance criteria, breaking the story down into smaller stories that still add perceived business value and having the Sprint team as a whole gain enough understanding of the request to prepare an estimate
- Notes: The user story will be presented by the Product Owner as ready for estimation Some discussion will take place to clarify the known details and acceptance criteria The Sprint team will attempt to size the story Typically this is done by assigning a story point (size) to the user story using other known stories as a guideline for comparison Once a user story has been estimated, the story is ready for the sprint team to bring into a sprint iteration The story point outcome of the story may influence its priority The user story’s priority will decide which sprint iteration it will be completed
- Notes: The sprint team will choose user stories to bring into a new sprint at the start of the sprint This is determined by the priority in the Sprint Teams product backlog Before a sprint team will consider a user story for their sprint; A user story must be small enough to fit into the teams available time for a sprint A user story must be understood by the sprint team A user story must be estimated The sprint team will accept the story into their sprint All known implementation tasks will be defined during the sprint team’s sprint planning If the total hours needed to implement the story fits into the teams available time, the story will be brought into the sprint The sprint team will work on the implementation steps to complete the story during the defined sprint iteration The Product Owner will be involved during the implementation to verify the implementation is meeting the expected acceptance criteria The Product Owner will make decisions as questions emerge during implementation to help the sprint team meet the story acceptance criteria At the end of a sprint iteration, the user story will be reviewed The sprint team will demonstrate the perceived business value to the Product Owner If the user story meets the acceptance criteria, the Product Owner will accept the user story, it will be closed and returned to the backlog If the user story does not meet the acceptance criteria, the Product Owner will reject the user story, it will be returned to the backlog for reprioritization and will become available to be taken into another sprint for completion