Facilitating Purposeful Agile Meetings
The course is part of this learning path
This module takes a deep dive into everything that makes sprint planning effective, including having a strong definition of done, how to use velocity and capacity to your advantage, and how to deal with impediments.
The objectives of this course are to provide you with and understanding of:
- What sprint planning is
- How to create a strong definition of done
- What velocity and capacity are, and how to calculate them
- How to deal with impediments
This course is aimed at Scrum Masters who want to improve their individual knowledge of facilitating scrum events in service to their Scrum team and their wider organization.
There are no specific pre-requisites to study this course.
We welcome all feedback and suggestions - please contact us at email@example.com to let us know what you think.
- 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.
Tony has over 20 years’ experience in Business Development, Business Change, Consulting, and Project/Program Management working with public, private, and third sector organizations.
He has helped organizations to design and create processes and procedures to align ways of working with corporate strategy. A highly motivated and detailed solution provider, utilizing a wide range of methods and frameworks to provide structure whilst promoting creativity and innovation.
As a confident and self-motivated professional with excellent communication skills, Tony is able to bring people together and get them working as a team quickly.
Tony is an Agile and Scrum trainer with a vast knowledge spanning IT Systems, Business Change, Program and Project Management. With excellent presentation skills and a solid background, he ensures that all clients gain maximum benefit from his training. He has successfully guided those new to the industry through their initial training, helped experienced staff as they progress in their careers, and worked at the director level advising on best use and practice, as well as tailoring courses to fulfil the exact needs of clients.