Pain is temporary, failure lasts forever

Lean, agile living for the running mother of Peter

2008-01-13

Deciding on a sprint length

One week with one day long sprints. So, what is the verdict. Well, the first question is who decides on sprint length?
In our case, I've told the team when and how I want deliveries. AKA sprints from my perspective. Since the delivery and product increment needed are bug fixes the scenario they works with include fixing bugs. But we had a testing debt which meant we didn't know which bugs were highest prioritized. So, to accomplish the task, they decided on shorter sprints: they could not commit to a bug list which was not complete. So, they decided on one day long sprints and gave the testers some time getting back on track with testing. Every day the product backlog was filled with new bugs.
On Friday, I do believe we finally was back on track, having gotten a better picture of which bugs are present. And I can tell the team that these tasks are needed to accomplish the objective of the scenario.
If this means that the team will turn to longer sprints is up to the team. The over head costs for one day sprints are huge and causes frustration in some cases, team members feeling they cannot work undisturbed. But I don't believe that sprint length is something a product owner can force on a team, he can say how often he wants to be presented with product increment but the team needs to decide which flow they need to have to be able to deliver.

Labels:

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home