In my last post Scrum Events #1 The Sprint I’ve started the Scrum Events series and described the first event in Scrum - Sprint. I will continue my chronological approach and today I would like to tell you more about Sprint Planning. Please take into consideration that some parts of the Sprint Planning that I described are not explicitly explained in the Scrum Guide and I used examples of the common practices or my personal opinion.
SPRINT PLANNING - DEFINITION AND LENGTH
It is the event happening at the beginning of each Sprint. During Sprint Planning, Scrum Team (Development Team, Product Owner and Scrum Master) collaboratively creates a plan of the work for the upcoming iteration. The meeting is time-boxed (the same as all events in Scrum) to a maximum 8 hours for a monthly Sprint. Of course in case of shorter Sprints, the time is adjusted.
To help you understand the Sprint Planning, I would like to continue my analogy to sport from the previous post. This event is like the moment of the start in sprinting (short distance running). If you start running too fast, before the signal to begin, the whole race must be restarted due to false start. On the other hand, if you miss start, it can jeopardize your whole run and final result.
It is exactly the same in Scrum. Scrum Team needs to work together to start the Sprint, if someone will start before others, transparency will be lost and it will have a huge impact on the Sprint. Additionally, any delays in start, misunderstandings and not clear requirements can also delay the Sprint and negatively affect the final outcome of the Sprint.
In my opinion the first part of the Sprint should be focused on the explanation of “Why?” by the Product Owner. In the Scrum Guide it is explained shortly:
The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.
I would add to this description an explanation of the high level idea for the product:
- What are the business objectives of development of the product?
- How did the Product Owner select part of the Product Backlog that should be done during the Sprint? Is it because it’s more valuable for the client?
From my experience I can tell that it is much easier to start working on something if you know the background and understand the purpose of your actions. Of course details for each part of work should be explained in the work item’s Acceptance Criteria, but it is important for the Development Team to understand the whole picture.
It will be helpful if the Product Owner starts from the Sprints Roadmap, and then will explain what is expected from the current Sprint. I like the roadmap analogy, because I imagine that as a Scrum Team we are starting the trip together. It is much easier to achieve the first goal if we know roughly about the next destinations.
The next step of the planning is a more detailed explanation of what should be done. Product Owner his/her idea of Product Backlog items that should be done during the upcoming Sprint. Remember that it doesn’t mean what must be done during the Sprint!
If it is not the first Sprint, there are some inputs to the Sprint Planning session like:
- Projected capacity - total number of hours that the team will be available during the Sprint
- Velocity - quantity of work that can be done based on the last Sprint
- The latest increment - some of work done during the last Sprint and the value from all previous Sprints
As I mentioned before, the Product Owner proposes work items for the Sprint, but it is up to the Development Team how many items they will select. It is one the first moments in Scrum when PO needs to trust the team that they will select the right amount of work based on their expertise and previous experience. Nobody knows better how much work they can do during the Sprint than themselves.
The next step of the Sprint Planning is setting up the Sprint Goal by the Scrum Team. It is the objective that they want to achieve during the upcoming iteration. It helps the team focus and understand why they are doing their work. You can read more about its importance in the Scrum in my post Sprint Goal - Why do we need it?
Once the Development Team knows why they need to do the work during the Sprint and they decide what will be done, it is time to decide how it will happen.
It is not mentioned anywhere in the Scrum Guide, because it seems to be obvious, but the team needs to know how they will be checking daily if they are going into the right direction with their work. How do they plan to track the work, communicate with each other? This part can be done either in some not official meeting in Scrum before the planning session or during the Sprint Planning event.
There are some technical aspects that need to be agreed like by the team:
- How will the Product Backlog be reflected? Do they plan to use post it notes or do they want to have some online tools to manage it like Jira, Azure DevOps or Trello?
- How will they track the progress of our work? Do they want to use for example Kanban Board? If yes, will they use columns “To do”, “In progress” and “Done” or others that will be more accurate for their work?
- Would they like to use tools like Sprint Burndown or Burnup chart to see if they are still on the right track in order to achieve the Sprint Goal?
- How about bugs? Do they consider having items called “bugs”? If yes, how do they plan to manage them?
- What about communication within the team? Do they plan to communicate only face to face or using emails, Microsoft Teams, Zoom or any other tool?
It is possible that there will be more technical aspects that Scrum Team should discuss. I think that it is important to talk about them and have the common understanding of communication and the whole collaboration process.
TASKS AND DEFINITION OF DONE
The list of items selected for the Sprint is called Sprint Backlog. When it is created, the Development Team needs to decide what does it mean for them that the work item is “Done”. For every team it can be different, depending on the industry, type of product etc. This definition needs include all actions that will be performed to have the highest quality of the job e.g. testing or code review. Definition of “Done” expresses some verification of the level of value important for the team.
The Development Team decides how they will manage the Sprint Backlog.One of the most common approaches is to divide work items selected from the product backlog into smaller pieces. In that case Product Backlog Items are called user stories and they are divided into tasks. Tasks are representing all the work that is needed to achieve what is required and explained in the user story. One story can contain multiple tasks. The work required for completion of a task should be a day or less, so the Development Team can track the progress daily. The Development Team can invite other people for the Sprint Planning, if they need any technical advice.
Once the Development Team discusses all the work required for Sprint Backlog items to be “Done”, it is time to decide the size of the user stories. There are multiple ways to handle this part, but the most important rule is that it should not be done using hours. The Development Team can estimate the effort required to complete the user story but spent time may vary depending on the experience or skills of the person who will be working on it. The estimation is used for the team to measure their velocity - amount of work they can tackle during one full Sprint. It is a great tool for planning the next Sprints.
If a team would measure velocity using hours, it can be used by management for controlling purposes and we definitely don’t want this scenario to happen. Creating the controlling environment will decrease efficiency of employees and will affect the transparency of the team.
As I mentioned before, the effort can be estimated multiple ways. One of the most popular are:
- Planning Poker using the Fibonacci sequence
- T-Shirt sizes
- Dot Voting
Once all the work is estimated and planned, the Development Team can start their work. If they discover that they didn’t select enough items for the Sprint Backlog or they selected too many, it can be re-negotiated with the Product Owner. It is important to highlight that the Sprint Backlog is owned by the Development Team and it’s up to them how they will organize their work in order to achieve what they planned during the Sprint Planning session.
The most important takeaways from this post are:
- Scrum Team (Development Team, Product Owner and Scrum Master) should attend the Sprint Planning meeting. Development team can invite others to provide technical advice.
- Sprint Planning is time-boxed to 8 hours per monthly Sprint.
- The Product Owner should explain the background of the work required for the Sprint - the “Why?” part.
- PO needs to explain what is expected to be done, but the Development Team will decide what they can do based on the discussion and estimation.
- The inputs to the Sprint Planning are: projected capacity, velocity and the latest increment.
- Based on the discussion, the Scrum Team should set up the Sprint Goal.
- It is important to discuss how the Development Team will be working during the Sprint - all technical aspects: tools, boards, communication etc.
- Definition of “Done” is required to measure when the work is completed.
- Product Backlog Items should be divided into smaller units - e.g. tasks (1 day or less of work)
- The Development Team should estimate how much effort is required to complete Product Backlog Items/ user stories selected for the Sprint.
- Sprint Backlog is owned by the Development Team