The Sprint Planning meeting is the start of the Sprint and is the opportunity for the Scrum Team to discuss what they will build during the Sprint and how they will build it. The focus of the meeting is on choosing Product Backlog Items (the goal for the Sprint) and then breaking those Backlog Items down into a detailed list of tasks (the Sprint Backlog). In Sprint Planning, choosing who will do the work is strongly discouraged. The value of Sprint Planning comes at three levels: first, setting a concrete goal helps with team cohesion and enables high-performance teamwork, second, the planning work helps set expectations with stakeholders and develop a team’s understanding of its own capacity, and third, the time set aside for planning gives the team a chance to think systematically about how to respond to feedback from the previous Sprint.
The length of a Sprint determines how quickly a Scrum Team can “inspect and adapt” to changing circumstances and learning. Scrum, as a tool for product development, sets an upper limit to the duration of a Sprint. In other words, Scrum sets a minimum for the frequency of the inspect and adapt cycle. This ensures that teams using Scrum get at least a certain minimum benefit. Scrum does not set a maximum frequency (minimum Sprint length). If a team has a five-week (or longer) Sprint, the benefits from Scrum rapidly drop off. In particular, you dramatically increase risks associated with short term planning, responding to change, team development, windows of business opportunity, and error detection. Having a cycle longer than four weeks is not Scrum and a team with such a cycle length should not claim to be using Scrum.
Note: some references say that the maximum Sprint length is 30 days or one month. This is considered essentially equivalent to a maximum length of 4 weeks. Please see our article about Factors for Choosing a Sprint Length for more specific and practical guidance about this topic.
The Sprint is the fundamental unit of work when using Scrum. Any product development effort using Scrum is, therefore, divided into Sprints. Sprints are fixed in length so that the team has a predictable amount of time available to them to do work, which in turn assists in both short and long-term planning. By making every Sprint the same length, the Scrum Team learns its own capacity for work. If the Sprint length changes, the rhythm of Scrum is broken and a team will have to re-learn its capacity which usually takes at least a few Sprints. If Sprints are rarely the same length, then the Scrum Team will struggle to do any reliable planning.
I am starting a new series of brief articles that go through the details of the Scrum process, artifacts and roles. These articles will be one or two paragraphs each and will have a razor-sharp focus on the fine structure of Scrum. I have found that many people know the broad strokes, but are often missing important details. I hope you find these articles enjoyable and informative.
Neat little article: The Atomic Rules of Kaizen. From the article:
Systems that are internally consistent and externally pragmatic stem from just a few rules. Systems with exceedingly many rules typically fail or will not endure….
In Kaizen, it is important to have fidelity to just a few atomic rules, from which a range of behavior will originate. Below are the rules that I subscribe to:
- Spend no Money
- Add no People
- Add no Space
- Add no Steps (Touches)
I like the idea of having simple rules like this. The short list is memorable.