Sprint Backlog – Life cycle of a user story in a Sprint 

A Sprint backlog contains a list of stories and defects that your team has committed for a given sprint. Each story or defect in the Sprint backlog has a life cycle resulting in one of the possible states shown below. Using this, your product owner and your team could identify the subsequent actions during your Sprint Review.

State diagram for user story

“Not Started” – Initial state after Sprint Planning

All stories (and defects) in the Sprint backlog remain in “Not Started” status until the team can begin working on a task. The status changes from “Not Started” to “In Progress” when the team begins working on one or more tasks. Since the sprint backlog is prioritized, the team would normally begin working on items that are most valuable to your product. Your product owner may have also grouped stories under Minimum Marketable Feature – a smallest possible set of stories and defects that can be deployed to your production environment.

“Done”– The desired state before Sprint Review

Stories in a Sprint Backlog transition from“In Progress” to “Done” when the team completes all tasks for that story and fulfills the definition of done for a story. In addition to meeting the acceptance criteria, the tasks for definition of done may include design, development, unit testing, functional testing, code review, etc.

“Accepted” – The desired state during Sprint Review

Your product owner would “Accept” a story if the team can demonstrate successful completion of the acceptance criteria. A Story that was accepted can then be treated as “complete”. The Story can be “removed” from the Product backlog immediately or after it gets deployed successfully to your product environment. In rare circumstances, your product owner may reopen a story if it was closed accidentally.

“Incomplete” 

This depicts a state, where the team committed to a Story during the sprint planning, but the story was deemed “incomplete” during your sprint review session.

A few triggers for an incomplete story –

• Some or all tasks for this story were not completed before the Sprint Review session.
• The definition of done for the story was incomplete.
• Unable to demonstrate or fulfill the acceptance criteria for the story. In general, the story is incomplete even if one acceptance criteria is not met.
• All tasks were completed for the story, but the story may have introduced a new defect that would force this story from getting deployed.
• During the sprint review session, your team realized that the actual size of the story was larger than when they planned or estimated this story. This may be a common scenario for newly formed product teams.

Possible next steps:

• If feasible, some teams may choose to split an incomplete story. A story can be split when your product owner feels there is immediate value in consumers experiencing the completed portion of the story. The remaining portion of the story may be added to the product backlog for consideration in a future release.
• The entire story could be retained as incomplete and prioritized for a future Sprint/Release.
• If the story’s acceptance criteria is met, but it introduced a new (but less critical) defect, your product owner could accept the story and log a new defect upon releasing it to production.

 “Rejected”/”Canceled” – An uncommon scenario

This depicts a condition where the team committed to a Story during the sprint planning session, but the product owner in consulting with the team, decided to reject the story, indicating that it is not required for the product. Prior to the Sprint Review, the story may have remained in “Not Started”, “In Progress” or “Done” status.

Possible reasons for rejecting/canceling a story:

• A change in market condition forced the product owner to decommission or reject a particular story.
• An impediment exposed challenges from an architecture or solutions perspective, requiring one or more stories to be rejected.
• A Key performance indicator tied to a previous release may have forced a story to be rejected.

Possible next steps:

• When a story “In Progress” or “Done” is canceled or rejected, your team may need to remove the underlying source code, retest and package it for deployment.
• Your product owner could remove the rejected story from the backlog.
• In some instances, your product owner could update the acceptance criteria for the rejected story or could split the story.