- Scrum works using sprints. But it's best to know what is actually going to happen in the sprint. That's where sprint planning comes in. Sprint planning is where the scrum team plan what work is going to happen in the upcoming sprint. The goal of sprint planning is to figure out what product increment is going to be released at the end of the sprint. Sprint planning essentially asks what work does the development team need to achieve to release this particular product increment? It's used to set the goal for the sprint that everyone in the dev team works towards. So, what happens in a sprint planning session? Normally a sprint planning session lasts up to eight hours. This is for a one month sprint, shorter sprints have shorter sessions. The event is time-boxed, meaning that the session cannot exceed the time set, otherwise valuable time is being spent not working on meeting the sprint goal. The scrum master need to ensure that sprint planning happens and that everyone in attendance understands the purpose of the sprint planning session. They also need to ensure that the planning session doesn't exceed the time-box set. To figure out what needs to be planned in the sprint the dev team needs to ask itself two questions. One, what can be done in this sprint? And two, how will the work get done? So one, what can be done this sprint? The dev team needs to forecast what the product increment should look like at the end of the sprint. What functionality should the product have? What stage of release should it be at? The product owner discusses the objective that the sprint should aim to achieve in order to meet the sprint goal. These objectives are normally product backlog items. To find out more about the product backlog, check out the product backlog video in the scrum artifacts section. The product backlog, latest product increment, projected capacity and the past performance of the dev team are all inputs into the planning session. This all needs to be considered when planning the sprint. Given this, the dev team are the only ones who can assess what it can accomplish in the sprint. Externalities, such as team members being away on holiday, need to be taken into consideration, for example. The scrum team crafts a sprint goal. The goal is the objective that will be met within the sprint and the items that are picked from the product backlog are worked on to meet the goal. Remember, the sprint goal needs to be one, clear. Two, achievable. Three, meaningful. And four, visible. And two, how will the chosen work get done? With the sprint goal set and the items from the product backlog selected, the dev team decide how it will make a done product increment in the sprint. All of the items from the product backlog, as well as the plan to deliver them, are collectively called the sprint backlog. The dev team will normally figure out the work that is needed is convert the product backlog item in to an actual product increment. The item will normally be broken in to multiple pieces of work of varying size or estimated effort. Enough work should be planned for the dev team to forecast what it can achieve in the upcoming sprint. The dev team will self-organize who will undertake which pieces of work in the sprint backlog. The product owner should help clarify the product backlog and can make trade offs with the dev team. If the dev team determines it is too much, or too little work, it can work with the product owner to make amends, adding or removing items from the sprint. At the end of the planning session, the dev team should be able to explain how it intends to work to achieve the sprint goal and create the increment. Sprint planning is fundamental to the sprint, without it there is no direction for the sprint.