What happens if your team consistently fails to meet its “Definition of Done” for some or all of its stories. Should they extend the sprint boundaries? How should the product owner handle the situation? In the particular case the person asking the question noted the team was using 4 week sprints.
Victor Hugo de Oliveira noted that you shouldn’t extend the sprint explaining that a sprint is the basic timebox of Scrum, the purpose of which is to help focus the team: “A Sprint ends when the time ends”. He also suggests that the team focus on completing the stories (i.e. Done, Done) even if that means they’re only able to tack 90% of the stories originally committed for the sprint.
Jussi Mononen says that stories that aren’t completed in one sprint spill over into the next sprint at the discretion of the product owner. Angel Lopez tells of a case where:
One case: in a fixed time project, we "mis-evaluated" the cost of implementing a feature. And the start of the next sprint, the PO decided to forget that feature, it was more important for him to continue with the next story. And the current story, without that feature, was acceptable to him.
Adam Sroka coaches teams not to start stories they can’t finish in the sprint and not to start all the stories at once, allowing the PO greater flexibility to change priorities between sprint boundaries.
Jussi also suggested that this implies the teams are over committing, instead they should communicate as soon as they know they can’t deliver all the features expected in both the sprint and release.
Roy Morien makes a couple of points:
- A sprint length of two weeks: “it is a shorter time horizon, therefore easier to plan with a bit more certainty, it gives more frequent opportunities for demonstration of progress. Although I have no stats to support this, I would suggest that this shorter period makes for a more controlled sprint, less unfinished work, more accurate estimates of achievement in the sprint, a greater sense of urgency and commitment, and overall a better psychology and focus in the team environment.”
- The almost finished, untested stories represent components that might sink the project as the doesn’t know how they fit and what issues they hide.
It was also asked why the team wasn’t using free tools like FitNesse, RobotFramework and Cucumber to write their acceptance tests.