Consistently Not Done, Done, Done at the End of Sprints?
- Share
-
- |
Read later
Reading List

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.
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.
Rate this Article
- Editor Review
- Chief Editor Action
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Likelihood achieving done, proportional to self-organization level of team
by
Norbert Winklareth
Re: Likelihood achieving done, proportional to self-organization level of t
by
Sarah Toogood
Aren't sprints timeboxes where things that don't fit drop out?
by
Marcel Sorger
In situation where everything is equally important, most commonly that everything is a must have and nothing can be dropped, there is no time box only a deadline.
In those cases the time box is just a formal way of having periodical checkups by management. Nothing wrong with that, but it's more efficient to know up front what management thinks is really important, so you can focus on those features and if you have some time left spend some on the less important once.
The important thing for any kind of planning should be doing the right thing for the customer and manage customer expectations. The more you meet with the customer and the more clear the demands, the progress made and the options to steer the better the result of the project.
Extending the boundaries of the time box because of things not being done is just silly, unless you can't get any work done because of all the meetings. Things consistently not being done is a sure sign of features not being small and detailed enough. Dividing them up will be more work for the planner and if that is something that is done by a coder he will complete less features and the project will actually produce less.
The 4 week sprints should be halved to the more regular 2. This will give the customer more feedback and more moments to steer the project.
By doing both you increase the feeling of the customer of being in control by introducing more overhead and thus be less efficient.
It depends on the type of client and the level of trust he has in your project how much control he wants. Normally clients want more control, but it could be that the client is internal to your organization is more concerned with efficiency and doesn't mind a few things not being done.