In our previous post we introduced the agile trends and the Scrum methodology. In this article we want to help you to successfully run a Sprint Planning ceremony, and in particular to support those who do not have much experience in this area.
This scenario is just an option, experienced Scrum teams can follow other tools and other schedules.
SPRINT DESIGN GOAL
The first and most important thing about events is to set goals. The aim of Sprint Planning is to
- to compile and define the Sprint Backlog
- prepare a plan for its implementation and presentation, and
- all members of the Scrum Team are committed to its fulfilment.
For Sprint Planning to be successful, it needs the Product Backlog as input and the Sprint Goal set by the Product Owner. The end product of the ceremony is, in a good case, the Sprint Backlog and the plan for its implementation. All members of the Scrum Team are recommended to attend the event, including the Development Team, the Scrum Master and the Product Owner.
LENGTH OF THE SPRINT PLANNING
The question often arises: how long is it appropriate to hold this ceremony? The recommended length of the Sprint Planning is relative to the length of the Sprint. Our rule of thumb is that the Sprint length in weeks should be twice the Sprint length in hours. For example, for a 2-week Sprint, aim for planning in 4 hours.
This ceremony is often not easy to conduct and carry out effectively. In our experience, it can help both Development Teams and Scrum Masters to try to plan along the following 8 steps.
Step 1: Determine the length of the sprint
One of the important results of the Sprint Planning is that the date of the Sprint Review (demo) is set. The length of the Sprint must therefore be decided. Since agile trends typically operate with time-boxes, i.e. the time and cost dimension is fixed, this is critical. This allows the team to estimate how much work can be accomplished over the duration of the Sprint.
The appropriate length of a Sprint is entirely project dependent. Product Owners generally prefer short Sprints, while development teams prefer longer ones. Some experimentation is recommended to determine the length of a Sprint, but it is not worth spending too much time researching, start with a time you feel comfortable with and then change it if you feel the need. Once you have found the right Sprint time, it is worth sticking to it in the longer term so that the Scrum Team can incorporate this rhythm.
Step 2: Capacity planning
Knowing your capacity for the Sprint is essential for a credible, actionable plan. Team members should think about holidays, other project workloads and their commitments during the Sprint, i.e. who, when and how the team will be available during the Sprint.
Step 3: Set a Sprint Target
The Sprint Goal contributes to motivating the Scrum Team and helping them work together. We're all in the same boat, but it doesn't matter which way we pull. The definition of the goal is up to the Product Owner. Perhaps, if no goal has been defined yet, we can ask the Product Owner the question "Why shouldn't everyone take a holiday in the next Sprint?". The goal justifies why we are doing this Sprint, why people are coming to work, so it is important that the Product Owner comes up with it.
Step 4: Discuss the Product Backlog elements, select them for the sprint
The team will start looking at the highest priority items in the Product Backlog that are needed to meet the Sprint Goal. The review is a dialogue within the Scrum Team to make it clear to everyone what the Backlog item is about. Backlog items have been written about before, most often they are Epics, User Stories, Spikes, but they can also be Features or for example Use Cases. The application of these varies in many places, but in all cases it is important that the team understands and applies them in a consistent way.
An important part of the dialogue is to clarify the acceptance criteria for the Backlog items, i.e. the specific expectations. Once everyone is clear about the Backlog element, a decision can be made on whether to include the element in the Sprint Backlog, i.e. the Sprint scope. Velocity, the team's development speed, plays an important role here, as it is the basis for estimating and filling the team's capacity.
If the team is just starting out and has no experience with Velocity, it is worth taking a cautious, common sense approach to estimating the team's capacity. The aim is not to have a successful first Sprint and hit the right Velocity straight away, this will develop over the longer term (typically 2-3 Sprints) and will adjust based on experience.
Step 5: Review and review the Definition of Done
The Definition of Done is responsible for the quality of the Scrum Team's work, as it allows the team to decide whether or not the item is considered done. It should be reviewed and revised before each Sprint if feedback or a new requirement brings the need for it.
Step 6: Planning tasks, tasks
Planning, breaking it down into tasks can take up to half the time of Sprint Planning. Here the team has to prepare a solution plan for each Backlog item selected. It may also be useful to identify critical paths and dependencies to make it clear on which Tasks the Sprint may slip and to avoid team members crossing each other. Tasks should be time-estimated and divided between them. The time estimation can be used to check whether the work to be undertaken in a given Sprint really fits in.
It is also important to account for meetings and other tasks during the Sprint that take time away from development. A good practice is to use the "Planning Glass" tool, where you draw a big glass with the same capacity as the Sprint (measured in hours) and start "pouring" in the duration of tasks, meetings, buffer times and other tasks. If the glass overflows, then you need to adjust some of the Backlog items you have selected so far, or even the Sprint Goal.
Sustainable improvement is more important than reaching maximalist goals with overtime. Let's do the math, if you subtract only the time for ceremonies, coffee and lunch breaks from the daily planned working time, a two-week Sprint will leave a net of 6 days for actual work in a good case. The net development time is not 8 hours per day (which is what sponsors and clients like to calculate), but rather 4 hours per day.
Step 7: Examining the workload of team members
After scheduling the Tasks, let's check that no one is overloaded within the team, trying to evenly adjust the loads. It is in the team's best interest to avoid stowaways or unrealistic commitments.
Step 8: Commitment to the plan
All the work that has been done so far is only worthwhile if we have the whole team on board, everyone understands and commits to the plan that is produced by the end of the Sprint Planning. There is still time to clarify assumptions and misunderstandings.
Customizability
We must stress that the above steps are intended as a guide, not a set recipe for success. The course of ceremonies, including Sprint Planning, is tailored by the team, so these may evolve and change as the reserves identified during the Retrospectives are continuously improved. One of the drivers of this evolution is the Scrum Master, who provides the team with the right tools and approach to help them work effectively.
It is also important that from a project perspective, the process does not start with Sprint Planning. Sprint Planning must be preceded by a series of steps that make Sprints meaningful. It is therefore advisable to identify users, anticipated needs, and a return on investment calculation may also be necessary to ensure a sound project launch. The driving force behind this process is the Product Owner, who, with the active involvement of the team and the support of the Scrum Master, can take the "project dream" through a release planning to a concrete product definition, i.e. the Product Backlog, the prioritised list of requirements.
Training opportunities
If you would like to gain more experience and learn about other methods related to the Scrum Master tasks, we warmly recommend our practical Scrum Master training, where the Scrum Master's tasks are performed on a specific project with the participants, who can experience the most common challenges, pitfalls and ways to deal with them.
For Product Owners and Project Managers, we offer our hands-on Product Owner training, where we take a concrete project idea through to development in an agile environment and with tools.
Designabc