In this second post about Streamline’s ceremonies we look at the start of the sprint. Kickoff and Sprint Planning are standard scrum ceremonies that set the stage for the next two and a half weeks of work.
Kickoff marks the official start of each sprint. At Streamline our product owners identify their team’s complete sprint package at the start, rather than simply setting the team loose on an ordered backlog to do as much as they can. This practice developed out of a need to make commitments to stakeholders at the sprint level. While we’ve managed to reduce the need for that level of delivery granularity, we still follow the sprint package practice so that we can set stakeholder expectations.
The Product Owner “owns” the kickoff ceremony. In addition to the team, he invites any stakeholders who he thinks will be interested in the content of the sprint. This includes other teams, SMEs, perhaps people from marketing or sales, even, just possibly, a client representative. In order for this to work, each team’s kickoff has to be at a different time. We have a set schedule for these ceremonies as well as daily standups and product demos to ensure that any stakeholder can be at any ceremony without overlap.
We schedule thirty minutes for the sprint kickoff. Sometimes they take less time. The Product Owner presents each of the items packaged in the sprint. This is usually a mix of user stories, small changes, and bug fixes. The PO provides priority on the items. Sometimes a bug fix is the most important item, sometimes a quick change will deliver the most business value. The product owner also delivers the sprint goals, and clarifies which items in the sprint will be included in the Solution Demo at the end. Every item will be reviewed with the product owner when it’s done, but only items with high visibility and business value are demonstrated to stakeholders.
The team members can ask more questions about the items during kickoff. They’ve all see these items recently, since they’ve refined and estimated them within the last couple weeks. Nevertheless, questions do come up and sometimes conditions of acceptance are further refined. Stakeholders can and should ask questions to make sure they understand the scope of what’s going to be delivered.
When all questions are addressed, the PO asks the team for a vote of confidence (0 to 5, or “fist to five”). As during PI Planning, if confidence is less than 4 discussion ensues and, if necessary, scope is adjusted until all 4s and 5s are achieved.
Immediately after the kickoff, the team starts Sprint Planning. They shoo everyone else out of the room and begin by calculating their capacity in hours for the sprint. Our tooling (Microsoft Visual Studio) allows each person to put in their days off and their availability per day, then calculates the teams’ total capacity in hours.
Next they open up the highest priority item and review the conditions of acceptance once again. They start identifying the tasks needed to complete it. Some tasks are standard: Create the test plan, execute the test plan, design and implement the code, capture emergent requirements, update the database, prepare for the demo… They estimate each task in chunks of hours (see Estimation), combining small tasks so that the smallest chunk is three or four hours, or half a day. They work their way through each of the items in the package, identifying and estimating as much of the work as they can.
The planning meeting should not take more than 2.5 hours – or about one hour per week of sprint. If it runs long the team is probably getting into design discussions that should be tabled for later. If it runs much shorter, either they’re very good, or they’re not going deep enough – you can tell which as the sprint progresses.
One thing that sprint planning does not include is work assignment. Certainly there will be tasks that are an obvious fit for one team member or another, but nobody assigns anyone to anything during planning.
When they’re done planning, if the team’s planned hours exceeds their available capacity they need to speak to the Product Owner. Maybe they’ve over-planned or gold plated. Or maybe the process of analyzing an item has revealed more complexity than they realized before. The Scrum Master and any members of the team who are interested meet with the Product Owner to find ways to reduce the overall sprint package. They might reduce the scope of a large item by removing some of the conditions of acceptance, or they might remove an entire item from the sprint.
At Streamline we have a deadline of the end of the day after the start of the sprint for teams to renegotiate. This is to ensure that they get their planning done early enough to try to prevent disaster. It does not preclude them discovering complexity later in the sprint and renegotiating with the Product Owner then.