Consistently Not Done, Done, Done at the End of Sprints?
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.
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.
Likelihood achieving done, proportional to self-organization level of team
Re: Likelihood achieving done, proportional to self-organization level of t
Aren't sprints timeboxes where things that don't fit drop out?
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.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015