A day before the sprint ends, a problem is discovered in an important story that will prevent the team from completing the story. What is to be done? Push the story back into the backlog or extend the duration of the sprint? Pablo Emanuel says that you can either return the story to the backlog or cancel the sprint. He goes on to say that delaying a sprint violates the principles of iterative software development:
the whole idea behind iterative development is feeding back the process as frequently as possible. You'll feel tempted to delay it, specially in the beginning, but, by the same principle people that have a fixed schedule with a personal trainer show up more often at the gym than people that are free to go whenever they want, you should never delay your iterations.
In addition, he points out that the iteration demo is important even if there is only a tiny feature to show as it provides an opportunity to meet and review the last iteration plan.
Maurice le Rutte notes that: “admitting that you could not finish the item because of the defects you found will increase the team's credibility and thus trust. Delaying the demo will send an entirely other message, namely that you don't have your process in control and that you will be delaying all the time.” He goes on to remind us to thank the team for finding the problem early before the customer did and of the importance of using the retrospective to find out what happened to the story.
Dan Rawsthorne points out that holding the review and retrospective gives the Product Owner a chance to reprioritize for the next sprint and that might not involve the troublesome story.
Another team finds itself in this situation on a regular basis leading the Scrum Master to believe that there was a planning problem. Cenk Çivici asks why stories aren’t done: “Are stories too big? Do they have clear acceptance criteria ? Does testing take too much time? Do you have enough test people to finish stories ?”
Juan Banda reminded us of the INVEST acronym: Good User Stories should be:Independent, Negotiable, Valuable, Estimatable, Small, Testable and wonders if the small part is being violated.
Inanc Gumus explained that the team has only three members (beside the Product Owner and Scrum Master) and that they initially estimated stories as only taking 3 days. An example: "As an advertiser, I want you to stop delivering my campaign as soon as my campaign budget is depleted". The team thought that this was the smallest they could slice up the story.
Paul Hudson offered smaller stories that could later be connected into one bigger one: “As an advertiser, I want to be able to stop delivering my campaign at any point. As an advertiser, I want to be able to know how much I have spent at any point”. Ron Jeffries takes a slight different approach: “First story split out here might be "Given a depleted campaign, do not deliver it". This should come down to two things to do: business logic consisting of about one if statement, and hand creation of a depleted campaign. If it takes more than a half day, I'd like to know why.”
Mark Levison, this reporter, suggested that Inanc ask the team in a retrospective what they think is at issue, using root cause analysis and other retrospective tools. Its likely they already know some of the answer.
The consensus in both cases: alert the product owner as soon as the problem is discovered; demo the functionality that was achieved; allow the PO to reprioritize; use the retrospective to find the root cause; Don’t extend the sprint.