Let’s start with a question. When is the Sprint Planning over? Usually, the first answer that comes to mind is “when the time-box expires”. It is a good answer. However, Sprint Planning is a maximal time-box. We can end the Sprint Planning earlier, can’t we? Yes, when we are done with planning, we can go to work. How do you know you are done with planning? When we have identified all of the tasks. When everybody is fully booked. When we have no hours left. That’s where you got it all wrong. It is not the purpose of Sprint Planning to make sure everybody is busy. Even if, some electronic tools support it that way.
The what and how of the Sprint Planning
We need to answer two questions what is the objective of the Sprint and how are we going meet it.
The Product Owner comes with a proposal of the Sprint Goal and Product Backlog Items supporting it. The Development Team looks at the latest product Increment, projected capacity and past performance. Based on the data, the Development Team forecast what can be achieved. The whole Scrum Team collaborates on crafting the Sprint Goal, so everybody understands why are we building the Increment.
Then the Development Team builds the Sprint Backlog. They do it by designing the system and decomposing the work for Product backlog Items taken into the Sprint. There are many ways of decomposition and none is preferred by Scrum. The most common practice I see is splitting the Product Backlog Items into tasks. What is the proper size of a task? Good idea is to have tasks of the size of one day of work or less. This means that tasks are quite small. Why? It makes the Daily Scrum effective and progress of the work clear. When we have small tasks, everybody is able to get something done between Daily Scrums. But splitting all the work to small tasks can take a lot of time. Do we need to split all Product Backlog Items into small tasks? For some Product Backlog Items, it won’t make sense to split. For example, fixing a fairly simple bug. Then don’t split. For the rest, make sure that you have a fairly good plan for the first days of the Sprint. The rest of tasks will emerge during the work.
The challenges of planning the work
It is not possible to predict all the work in complex environment building innovative products. Decomposing the work is nothing else, but predicting the future based on assumptions. Some tasks are going to take longer, some are going to take shorter and there will be new ones. You start working on something and you can discover many new things you didn’t know. Therefore, the Sprint backlog is going to be updated constantly until the end of the Sprint. The purpose of the Daily Scrum is to look at the current state of the Sprint Backlog and decide what to do next to achieve the Sprint Goal.
There is also a misconception in terms of using the capacity of the Development Team for planning. Some believe that calculating the team capacity in hours and estimating all the task is the best way for to plan a Sprint. I think we all can agree that it will take a lot of time. Let’s look at using the capacity without detail calculation. Basically, check with your team if there are any holidays in the current Sprint or absences. Now, look how does it compare to full capacity and what is the impact to the Velocity. It is simple as that. Please, if you still want to go with precise calculations, remember to leave a buffer for the unexpected. The Development Team needs to feel confident with the forecast built. Pushing them for stretch goals will get you a squirrel burger at best.
What about the traditional resource and capacity allocation? How are we going to make sure that everyone is busy? Scrum is not about making everyone busy, it’s about building valuable products. Being busy is not the same as being productive nor creating value. As part of the Agile family, Scrum promotes the idea that the best solutions come from self-organizing teams. So let the Development Team self-organize around the Sprint Goal and update the Sprint Backlog accordingly during the Sprint. Having tasks assigned to individual team members ruins the opportunity to self-organize. Assigning tasks moves commitment and focus on delivering the Sprint Goal as a team to complete tasks assigned to me. Each member of the self-organizing Development Team shall pick next task when he or she finished the previous one. The selection of the new task shall be based on answering “What is the best thing I can do to help the Development Team meet the Sprint Goal?”. There is also no rule against multiple Developers working on the same work item.
When the Development Team discovers, that the work in the Sprint differs from the forecast built, they can negotiate. The Development Team can work with the Product Owner on removing or adding Product Backlog Items to the Sprint Backlog. The scope of individual Product Backlog Items can be also negotiated. Changes cannot impact the Sprint Goal. That is another way the Sprint Backlog changes during the Sprint.
Summary
The outcomes of the Sprint Planning are the Sprint Goal and a plan of delivering the Increment. The work that needs to be done is represented in the Sprint Backlog. Sprint Backlog needs to be detailed enough so that the Development Team can forecast the work needed. Bear in mind that we want to create only a forecast for the Sprint, not a bulletproof plan. For the first days of the Sprint, the work is decomposed to small units and the rest will emerge. Self-organizing Development Team decides how to do the work as they go. Changes in the Sprint Backlog will occur as the work emerges or as the scope is negotiated with the Product Owner.