A refresher by Russell Lewis, The Agiliser

There are three major planning ceremonies in Scrum. They are essential for Agile project management. These ceremonial meetings are:

• Sprint Planning Part A – decide WHAT can be done in the sprint
• Sprint Planning Part B – decide HOW the chosen work will get done
• Sprint Review – inspect what was done and adapt the backlog accordingly

Before examining the details of each meeting, we should state the purpose of each.

Notice that each meeting depends on the output of the previous one, so the order really does matter.

Sprint Planning

The input for Sprint Planning Part A is the Product Backlog. The output is a Sprint Backlog of stories selected by the Product Owner and estimated by the Team.

The Sprint Backlog is the input for Part B, from which emerges a task breakdown of each story. The tasks are quite detailed, often specifying names of classes and functions, diagram types and scopes, details of people that need to be interviewed, documents to research, etc.

Each task is given a time allocation in hours, so the Scrum Master can track the day to day progress of each story.

Sprint Review

At the end of the Sprint, the Team demonstrates everything that has been completed at the Sprint Review.

Based on the features they have just seen, and with their knowledge of the latest business activities, stakeholders update the Team and the Product Owner with information to help them plan the upcoming Sprint.

Then there are other the planning meetings.

Daily Scrum Planning Meeting

The 15 minute daily Scrum meeting is perhaps most famous because of the name and a clue to the sporting analogy that runs through the process itself. It’s also the simplest with just three questions to answer:

What did you do yesterday? (Review);
what do you intend to do today? (Plan);
is anything holding you back? (Check).

It allows the team to plan their day according to everyone’s output on the previous day.

Backlog Refinement

Yet there’s one more planning activity that is not so well known and is easily missed. Called Backlog Refinement, it is essential to effective Sprint Planning and to the success of a Scrum project.

According to the Scrum guide:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.

The problem is the word “on-going”. The guide suggests that “refinement consumes no more than 10% of the capacity of the team”, but there is no associated ceremony or prescribed list of participants. Worse, you only find out if you have done sufficient Refinement at the end of the Sprint Planning meeting.

If the Sprint Planning meeting went well, then you probably did enough. Most teams do not do enough and the Sprint Planning meeting suffers as a consequence.

Refinement is usually done by the SM and the PO working together, often including some other team member or subject expert.

The most successful POs spend a little time reviewing and tending their backlog each day, or at least every other day. This used to be known as grooming, but that term has other associations these days hence Refinement.

Since the purpose of Backlog Refinement is to prepare for the Sprint Planning meeting, let’s take a look at Sprint Planning next.

Release Planning

The Release Plan is like a product roadmap, providing transparency on key dates and deliverables. It is created very early in the project and updated regularly. It helps steer Sprint Planning and Backlog Prioritisation and as such, is a vital artefact for the Product Owner.

There will be technical considerations too, so whoever is responsible for architecture on the Team will generally help to define it.

Whilst it’s inevitable that the business will define the rate at which software is released to customers and stakeholders, this activity actually comes from XP and not from Scrum.

In Scrum terms the Release Plan is implicit within the Backlog and is a part of Backlog refinement.

Next time, I’ll look at how this meeting of two parts achieves its purpose.