The Daily Scrum is most effective when it is held at a regular time of day so that all team members can easily remember it, schedule for it, and it becomes a habit for the team. Although technically this is simply a guideline rather than an “official” rule, it nevertheless has a positive impact when done, and a negative impact when not done. If the team fails to have the Daily Scrum at a regular time, Team Members will need constant reminding of when it is going to occur, and there is a greater risk that it will be missed by some Team Members. Missing the Daily Scrum reduces transparency between Team Members. Another minor negative consequence is that if the Daily Scrum is not held at a regular time, then the Sprint Burndown Chart will have an uneven horizontal scale (if measurement is made at the end of the Daily Scrums) or it will be more difficult for the ScrumMaster to measure the state of the Sprint for tracking on the burndown (if measurement is made at a regular time of day independent of the Daily Scrum).
The Daily Scrum is designed to dramatically improve transparency among Scrum Team Members and out to any stakeholders who are interested in observing the meeting. The timebox is a fixed limit on the duration of the meeting. The 15 minute limit on the Daily Scrum is sufficient for each Team Member to take a turn and briefly answer each of the three questions required in the meeting. The timebox forces the Team Members to be brief, to be focused, to be on-topic and to be respectful of other Team Members’ time. If the Daily Scrum meeting takes longer than 15 minutes, some Team Members and stakeholders will stop feeling like the meeting is worth the time investment, particularly since it is daily. Even five additional minutes for a 12 person team adds up to a person-hour of time lost every day! Losing people’s interest or respect for the meeting will decrease transparency and can hamper the team in numerous ways, including the ScrumMaster’s ability to see and deal with obstacles in a timely manner.
After a team finishes its Sprint Review, the Retrospective meeting should begin immediately. Of course, there may be a small transition period as non-team members leave a meeting room or as the Team Members go back to their team room. However, there should be no work on the system done between Sprint Review and Retrospective. This quick transition between the two meetings is primarily to ensure that everyone has a clear memory of the Sprint. If there is a gap between the two meetings it can lead to a number of sub-optimal behaviours: team members may do work without the knowledge of the rest of the team, there may be a growing desire to delay the retrospective, or even pressure to skip the retrospective.
Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants. In Scrum, the combined length of the Sprint Review and Retrospective Meetings is determined by the length of the Sprint. For example, a one week long Sprint has Sprint Review and Retrospective Meetings that are timeboxed to two hours in total. It is acceptable for the meetings to take less time, but not more. A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours. Keeping the Sprint Review and Retrospective Meetings timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective inspect and adapt in a very short period of time. If the meetings are not timeboxed, then typically the team will keep going until they are “done”… and break the timebox of the overall Sprint.
The last part of the Sprint is the Sprint Retrospective. This meeting is a private meeting for the members of the Scrum Team (including the ScrumMaster and Product Owner). In this meeting, the Team Members discuss how they did their work during the past Sprint and come up with ways to improve their work in the next Sprint. Scrum does not define any particular techniques to use during the Retrospective meeting. The Retrospective is complementary to the Sprint Review. The Review inspects “what” was done and the Retrospective inspects “how” it was done. The Sprint Retrospective is critical for the team to apply the principle of “inspect and adapt” that is core to Scrum. Missing the Sprint Retrospective is a critical failure of the ScrumMaster’s job to ensure that the principles of Scrum are being used. If a Retrospective is missed once, what may happen is that some Team Members might feel that missing it was not so bad. There will not likely be any immediate consequences to missing the Retrospective. However, the attitude that the Retrospective is not important will be implanted in the team. This then quickly leads to further compromises and eventually, the continuous improvement parts of Scrum are abandoned and the team focuses purely on the execution parts of Scrum. The team will then fail to become a high-performance team since that high-performance state is predicated on systematic, conscious self-improvement of how the team does its work.
Mike has written another great blog post, this time about Scrum and the relationship to business… the need! to talk about business when using Scrum. Mike has really presented some important concepts about the big picture of Scrum as a catalyst for exposing problems that you have…. and that usually those problems are hidden and hurting your business!
One of my colleagues, Jim Heidema, does Agile Project Management with Scrum training for us. He recently ran a class for one of our clients. Part of the class is a simulation to build a comic book that tells the story of the Three Little Pigs. Here is one beautiful, unexpected outcome of that exercise!
Scrum is a tool for product development that uses transparency and fast feedback. The Sprint Review is an open meeting during which the Scrum Team works with all interested stakeholders to look at the results of the Sprint. This meeting is usually dominated by a demonstration of the working increment of software. The stakeholders in attendance at this meeting freely provide feedback about the product which is then used by the Product Owner to update the Product Backlog. This feedback is critical to ensure that the team is staying on-track, that it is building the most valuable possible product features, and that the stakeholders are satisfied with the results. Missing this aspect of feedback makes Scrum only modestly better than non-agile approaches to doing work and should be considered a critical problem to fix as it undermines the whole point of doing Scrum.
Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants. In Scrum, the length of the Sprint Planning Meeting is determined by the length of the Sprint. For example, a one week long Sprint has a Sprint Planning Meeting that is timeboxed to two hours. It is acceptable for the meeting to take less time, but not more. A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours. Keeping the Sprint Planning Meeting timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective planning in a very short period of time. If the meeting is not timeboxed, then typically the team will keep planning until the plan is “done” which usually substantially eats into work time.
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 phrase “potentially shippable” has a very simple meaning: the features built in a Sprint and all the related activities are done to such a degree that ONLY business considerations are involved in the decision to ship or to not ship at the end of the Sprint. Every Sprint should start with the intention of getting a small set of features to this ideal state. Of course, teams make mistakes and have obstacles to doing their work to this level of doneness. The intention to make potentially shippable software is designed to help teams see and expose obstacles to actually shipping. These can be technical obstacles, dependencies, or bureaucratic obstacles. Failing to have this intention removes this beneficial pressure from the team. This lack of pressure can in turn lead to acceptance of “the way things are” and a team that never reaches a high-performance state.
Each Sprint that a Scrum Team does is an opportunity for learning through “inspect and adapt”. If there is a break or a pause between Sprints, the Scrum Team may forget what it has learned or fail to apply that learning in a timely manner in the next Sprint. Of course, many Scrum Teams end a Sprint before a weekend and start their next Sprint at the beginning of the next week. This non-working break is normal and acceptable. However, a break between Sprints during which some or all Scrum Team Members do other work is not acceptable.
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.