When is a story too large for a sprint?

by Doug Shimp on October 12th, 2009
  1. It is never too large for the sprint. The team must learn how to meet business expectations.
  2. The team cannot agree on which stories to work  on during the sprint
  3. The product owner has prioritized the story into sprint planning without any written definition of done
  4. When the team cannot agree on how to commit to the story
  5. Teams are inherently anxious; SM/PO must challenge the team and not accept no for an answer.
  6. Make the sprint bigger so the story fits.

Comment: The Team may not be able to commit to a story, or might notbig-story-bite-epiceven be able to agree on “done.” This makes the story in question is an epic, by definition, and the Team must decide what to do. Typical choices include committing to an Analysis Story to figure out what to do about the epic, or extracting a smaller story from the epic to do instead (putting the remainder back on the backlog), or skipping the story altogether and moving to the next one. Bottom line: We need a sense of movement to understand what the team can and cannot do. Biting off chunks of work that are too large obscures movement and makes throughput / velocity that much harder to understand. Use the team’s ability to commit to understand the work that the  story represents.

Share

From FAQ

Comments are closed for this entry.