If release planning is the tuning fork, then sprint planning is the fine-tuning that a musician does before and during play. Since an instrument's tune is affected by its age and damage throughout the years, external factors such as the weather, and by the musician and his playing style, tuning is the way the musician brings the instrument back to the desired sound, matching usually an external source such as a tuning fork or digital tuner. In our Agile concerto, sprint planning is like fine-tuning the deliverables in the product backlog to the overarching pitch—or goals—set forth in the release plan. Just as instruments will get out of tune, so will a plan. But an Agile plan will never get too far out of sync since the product owner maintains a product backlog with the latest priorities and engages with the team in sprint planning. Sprinting allows the team and customer to readjust, or tune short-term deliverables to meet the...
Sprint planning is, simply, the time when a team plans its sprint; it happens on the first day of the sprint. Legacy Scrum tells us that we have up to eight hours to plan for a 30-day sprint. In the past five years, many teams have moved to two-week sprints, and sprints of one or three weeks are also common. In any case, when the sprint length is shorter than one month, it's logical that the team should reduce the amount of time spent in sprint planning. A two-week sprint, for example, should not require a team to spend more than four hours of sprint planning (and can usually be completed in just a couple of hours). I worked with a team a couple of years ago that planned its three-week sprints in 15 minutes. And they consistently completed 85 to 95 percent of their commitments. More planning doesn't necessarily mean better planning!
Weight Watchers is very similar to Scrum. When a person begins the Weight Watchers program, he/she initially weighs in so that there is...
If you're new at facilitating meetings, preparation, especially in the beginning, is extensive and burdensome. It will be, simply, trial and error until you figure out what works best for you and your team, in your unique environment. You should be your own worst critic; make observations and notes about what is and isn't working during your meetings, and ask the team members for their feedback as well. Meeting results are directly proportional to your preparation and your overall facilitation experience.
The product backlog powers sprint planning. Just as engines run more efficiently with high-octane fuel, teams can plan more efficiently with well-prepared product backlog items.
I've found Bill Wake's INVEST acronym to be the best readiness litmus test for PBIs coming into sprint planning. INVEST stands for Independent, Negotiable, Valuable, Estimatable, Small, and Testable:
Sprint planning has two parts: in the first part the product owner describes the stories he/she wants, why he/she wants them, and how they provide value or solve a problem. The product owner also answers clarifying questions from the team. During the second part of the sprint planning meeting, the development team members discuss the approach, tasks, ownership of tasks, and other tactics for meeting their commitments.
Start with the end in mind. The goal of each sprint is for the team to deliver a potentially shippable product increment—features that work, features that the customer can put their hands on. The purpose of sprint planning is to figure out how to do that.
The product owner drives the first part of sprint planning by giving detail about the most important items from the product backlog. As the product owner reviews and explains the stories, the team asks questions to clarify the product owner's needs. You can further...
You should always look for ways (and suggestions from the team) to make meetings shorter and more efficient. Retrospectives (Chapter 5, The End? Improving Product and Process One Bite at a Time) provide an excellent forum for adapting sprint planning as well as anything else that may need improvement. Some ScrumMasters even run a quick retrospective in the sprint planning meeting itself to capture ideas for improvement while they are fresh in everyone's minds! I was hired as a coach at one client to work with a number of teams, one in particular that completed sprint planning in 15 minutes; management thought they were slacking because they planned so quickly! After spending a couple of sprints with them I determined that their planning was sufficient. They completed what they committed to and the product owner was happy with the work. What more can you ask for? As I used to say growing up in Texas, "Don't fix it if it ain't broke!".
Over time, find ways to make...
You must first understand the reasons behind planning in order to run effective planning sessions. There are meeting mechanics that you as ScrumMaster should follow—game rules of sorts provided by the legacy Scrum literature—and yet even more importantly, you should strive to create and sustain a certain spirit in your meetings. Planning meeting are not crystal balls into which you or the team can look into and predict the future of a project; rather they are the reserved space and time in which a team envisions the possibilities, gets excited about the outcomes, and establishes urgency by acknowledging that only so much can be done in one small time box. Sprint plans are the result of detailed discussions between team members as they figure out how they'll deliver quality results by the end of the sprint. In Chapter 4, Sprint! Visible, Collaborative, and Meaningful Work, we will explore how a good plan supports a team as they work together during their sprint, and how plans change...
Xavier Quesada Allue's Visual Management Blog available at http://www.xqa.com.ar/visualmanagement/author/xavier/
Cohn, M., Agile Estimating and Planning (2006), Pearson
Demarco, Tom, Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency (2001), Broadway Books
© 2013 Packt Publishing Limited All Rights ReservedAuthor (1)
