Sprint Planning - Sprint Length
- I was wondering if anyone has given thought to or discussed the time spent planning for a sprint as it relates to the length of the sprint? I was thinking about it a bit this morning after listening to people discuss the pros/cons of a one week sprint. In the past our teams have always done two or three week sprints. The time spent planning the sprints seemed to correlate to the length of the sprint in that obviously the team was planning to take on more work in the longer sprint versus the shorter and thus planning took longer. My real question however has to do with the time spent in discussing the details of the stories and tasks. Our teams typically talk about the details of the story just enough to get a good sense of the amount of work required to complete the story. In a longer sprint there seems to be a bit of "wiggle room" to adjust for the unknown, but in a shorter sprint the team loses some of that luxury.
What experience or advice do people here have when it comes to the amount of time needed to discuss the details of a story/task during planning for shorter sprints versus longer sprints. Maybe it shouldn't make a difference but it seems to me that the shorter the sprint the more prepared and confident the team needs to be and this translates into more detailed sprint planning.
- Hey Wouter,
From what you're saying, it sounds like you're relying on longer sprints to hide inefficiencies in your current processes. Perhaps the team could inspect these and find ways to fix them?
On Wed, Jun 1, 2011 at 7:30 PM, Wouter Lagerweij <wouter@...> wrote:
This is a very useful discussion, thanks.Like Charles, I've been starting teams out with two week sprints. Mostly because, usually, there are plenty of difficulties for them to get any work done within those two weeks: CI and release building problems, backlog/story preparation, insufficient testing, etc. So I thought aiming for a shorter sprint would set the team up for failure, and might discourage them too much from using Scrum. I do always include a 'shorter is better' talk when choosing the sprint length with the team, but recommend two weeks.What you're all saying is that one week would be better, right from the start. I was wondering what the way do deal with the failure is. Or (since the obvious answer is: fix the impediments first, go faster later) what you do to keep the team positive and engaged with adopting Scrum when their first sprints fall far short of (their) expectations?btw, in Dutch we have a saying: "Zachte heelmeesters maken stinkende wonden", which roughly translates as "Gentle healers make stinking wounds", meaning a direct thorough treatment of a problem is usually better, because half-measure could make the problem worse. It seems appropriate in the context.Wouter--On Thu, Jun 2, 2011 at 12:48 AM, Ron Jeffries <ronjeffries@...> wrote:
Hello, Charles. On Wednesday, June 1, 2011, at 5:41:32 PM, you
>> I believe you are missing a lot by settling for two weeks.Fair point. I can't say my mind has changed on the matter, especially wrt to the team context for the teams I've coached, but I'll give it some consideration.
> Do you believe that to be true for most teams? Is it your view
> that most teams should do 1 week sprints?
New and stirring things are belittled because if they are not belittled,
the humiliating question arises, "Why then are you not taking part in
them?" -- H. G. Wells
Wouter Lagerweij | wouter@...http://www.lagerweij.com | @wouterla