Chapter 3: Sprint Planning – Fine-tune the Sprint Commitment
The project manager and the marketing manager are arguing in front of the technical team about the importance and order of product backlog items. They've decided to combine their most important needs and have stated that they have 50 critical items among which the team may choose which to deliver in the upcoming sprint. What is wrong with this picture? How might you handle the situation?
What tool does your product owner utilize for backlog management? Is the product backlog visible? Can anyone contribute to it? Does everyone know who the product owner is and what his/her responsibilities are? If the answer is no to any of these questions, please put an item on your Impediment Backlog to discuss and resolve this impediment.
Let's say that your team suggested that instead of tasking stories out during sprint planning, they would rather individually send you their tasks before the sprint planning meeting in order to save time. This way you can just total up the tasks and hours for the team and let them know in the meeting if they are over or under capacity. They are excited about the time savings of this approach, but you have reservations about this. What do you tell the team?
Please see the Sprint Planning Checklist in Chapter 3, Sprint Planning – Fine-tune the Sprint Commitment. What steps would you expect that you could alleviate over time, given that your team remains the same sprint after sprint? What general ideas do you have to keep meetings light, focused, and efficient?
During sprint planning, one of the team members wants to reprioritize stories because of some logical technical dependencies. What should the team do?
You are interested to know if the team have reached consensus on the plan, so you ask the team their opinions. All the team members feel confident except for John, who is concerned as he feels the team has selected an amount of work that might turn out to be too much for the sprint time box. What can you do to help John feel comfortable about the proposed sprint commitment?
While the team is tasking out the work, you overhear a lead developer assume that the feature should function a certain way, and then instructs everyone in the team accordingly. What is wrong with this situation, and how might you fix it on the spot?
Are you a good facilitator? A good facilitator:
Understands the team, its lingo and jargon, behaviors, and history.
Creates a sense of safety; that is, everyone is free to speak his/her mind in a space that will kindly receive it. "Together, with everyone's participation, we can come up with an outcome better than what one person could create. Nobody will be talked down to, and there will be no condescending behavior."
Is like the Switzerland of the meeting, remaining neutral but not afraid to stop bad behavior or layer on knowledge. This does not mean to choose sides, but rather to make information and data available that might help the team reach a conclusion.
Spends adequate time preparing for the meeting, creating scripts, agendas, games, ice breakers—anything necessary to help the team meet the goal.
Has an arsenal of tricks and skills to pull on at any given moment should the meeting's attendees need a perk or conflict resolution.
Is skilled in conflict resolution.
Creates tools to help team members remember action items (clean up).
Does not cut off people as they are speaking, or finish others' sentences, or make decisions on behalf of the team.
See Jean Tabaka's Collaboration Explained for more wonderful tips, tricks, agendas, and ideas.
