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.
How might we improve InfoQ for you
Thank you for being an InfoQ reader.
Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.
Community comments
The link "sprint length" is broken.
by Kondo Hiroki,
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,
The link "sprint length" is broken.
by Kondo Hiroki,
Your message is awaiting moderation. Thank you for participating in the discussion.
Where is the link target?
Likelihood achieving done, proportional to self-organization level of team
by Norbert Winklareth,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have observed that the less self-organized a team, which uses time-boxing, is, the more likely they will have significant amounts of started and uncompleted work at the end of the sprint. This is usually in the testing area. The counter-measure I most often use is to work with team on what the nature of commitment is and that they need to monitor and re-act when internal queuing of work occurs, by draining the queue before starting new work.
Re: Likelihood achieving done, proportional to self-organization level of t
by Sarah Toogood,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have found that by increasing the visibility of the sprint work the team becomes more self-managing and quickly learns to adopt best practice. For example, a simple whiteboard board with the list of work, the person who has accepted doing the work, the business priority and the status of the work enables all team members to check that they are working on the highest priority and that they are only working on one thing at once. The other benefit of this is that all items which have an impediment are highly visible and help them to become the top of people's to do lists so that they get resolved faster. Thus overall decreasing the likelihood of items not being done at the end of the sprint.
Aren't sprints timeboxes where things that don't fit drop out?
by Marcel Sorger,
Your message is awaiting moderation. Thank you for participating in the discussion.
I thought the whole point of time boxes was to have the must haves done and to drop some of the should and could haves. Considering you have typed the features in the time box by the MoSCoW rule and have a mix of those types in the time box.
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.