Establishing Rhythm on a New Scrum Team
By Lisa Montaño / Filed under Agile, Scrum / August 26th, 2012
One of the questions I hear in my 1-Day Scrum Foundations and Principles class is “How long should our new team’s Sprint be?”
The amount of work your team commits to during an iteration should be guided by the Sprint length, not vice-versa. Time boxing, or choosing a specific iteration length, is a central principle of Scrum, and requires discipline on the part of your organization (not to add more work into your timebox) and ensures that the team will work at a sustainable pace. The opposite of time boxing is determining your Sprint length based on how much work you have to complete by a date determined by someone other than the team—this is not Scrum. So pick a Sprint length and stick to it for a few iterations to give the team time to adapt and establish a rhythm.
The guideline for Sprint lengths is 1-4 weeks; most teams say that a 1-week Sprint is too short. By the time you’ve done the pre-planning, Sprint planning, and Retrospective for the prior Sprint, you could potentially have used a quarter or a third of your Sprint period and have very little or no business value to show for it. On the other hand, if your team seems to be losing focus at the end of the Sprint, can’t remember the issues or challenges of the Sprint during the Retrospective meeting, or just loses momentum, then perhaps you should consider shortening your Sprint.
While I think it’s important to consider how much experience the team members have working together, whether the technology is new, and the type of product you’re working on when determining your team’s Sprint length, I wouldn’t over-think it, just pick a Sprint length, and inspect-and-adapt at the end of each iteration to see if the team can make incremental adjustments to improve any inefficiencies or obstacles. If it seems like the Sprint length is too short or too long for your team, product, or technology, then make a deliberate decision to adjust the Sprint length.
So, how do you know if your iteration is too short? I wouldn’t necessarily say that your Sprint is too short just because you didn’t finish all of the stories selected for the iteration. You can just as easily select fewer stories for the next iteration and it can be as simple as that. Here are some reasons why you might want to consider a longer sprint than you started with:
-
External dependencies related to material lead-times or multi-team coordination
-
Slow turn-around time from end-users or stakeholders
-
Special contractual, regulatory, or other requirements (that add additional tasks to your Sprint backlog)
-
The cycle time for developing your technology or product is inherently complex and producing a potentially shippable product takes longer
There is no “correct” answer about how short or long your team’s Sprint should be. Your team, product, technology, resources, experience, and empirical evidence, will inform you about what’s right for your team. So by all means consider changing your Sprint length in response to some of these issues, but once you choose a Sprint length, stick to it for a while so the team can acclimate to estimation, planning, and execution based on a stable iteration length. As long as you continue to discuss issues that arise over the course of the iteration in your Retrospective meeting, your team will come to the right decision for your team, and a productive Rhythm will follow.
Related posts:
