Skip to main content

Scrum Events – Sprint Planning

The development work that will be completed during the Sprint is planned at the Sprint Planning meeting and involves the whole Scrum Team.

If your Sprint is a month long, then the Sprint Planning is time-boxed to 8 hours. If you have a shorter sprint, then the time-box is reduced relatively.

 

sprint planning process

 

In Sprint Planning the aim is to essentially answer two questions:

  1. What will be delivered in the Sprint?
  2. How will we do it?

 

What will be delivered?

The Product Owner discusses what they’d like to achieve from the Sprint while the Development Team looks at which Product Backlog Items (PBIs) can be implemented in this Sprint.
Only the Development Team select the PBIs that will be worked on, as they know best what they can achieve.

The whole team collaborates to create the Sprint Goal – a high level objective that will be met when all the PBIs for this Sprit are implemented. The Sprint Goal provides guidance to the Development Team on why they’re building the Increment. It also gives the Development Team flexibility on how the Increment will be delivered – they commit to achieving the Sprint Goal, not the PBIs.

 

How will we do it?

The Development Team discusses how it will create the Increment.

Product Backlog Items + a plan for delivering them = Sprint Backlog

The Development Team will break down the PBIs into much smaller tasks, of around one days’ effort or less.
A plan for the whole Sprint doesn’t have to be created here – the team only needs to plan work for the first few days of the Sprint. The later work will be planned as the Sprint progresses.

The Development Team can discuss the PBIs with the Product Owner in order to clarify the requirements, and can renegotiate with him if they have too much or too little work.
They can also invite additional people in order to provide technical or domain knowledge.

“By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and the Scrum Master how it intends to work as a self-organising team to accomplish the Sprint Goal and create the anticipated increment.”
– Scrum Guide

 

When to estimate

I often see confusion around when PBIs should be estimated and each team does it differently. Some estimate PBIs and not tasks, some estimate both PBIs and tasks and others estimate tasks but not PBIs! Below is the way we do it, but remember to Inspect and Adapt to see which way is best for you.

  1. PBIs in the form of user stories are estimated in Story Points during the Backlog Refinement Meeting. This gives the Product Owner an additional metric to use when ordering the Product Backlog.
  2. As the PBIs are already estimated, when it comes to Sprint Planning, the Development Team can focus on selecting the appropriate items for the Sprint.
  3. Before we estimate the effort required, we define the acceptance criteria for a task. This ensures the Development Team knows what’s required to complete the task and allows them to more accurately estimate.
  4. Once the PBIs have been split into tasks during Sprint Planning, we then quickly estimate these tasks. At this point, many teams will switch to estimating in hours, but I don’t agree with switching metrics. So we again estimate in Story Points. Most of the time Development Teams members will be in agreement on the estimate for a task, but occasionally there will be a larger difference. This can be useful in highlighting technical issues that not everyone has thought of.
    As the team matures, it’s possible that they can do-away with estimating individual tasks.

We’ll look at the whole process of estimating, and the different techniques you can use to perform it, in a later post.

Scrum Events – The Sprint

Events in Scrum are used to create consistency and reduce the need for additional meetings that aren’t part of Scrum.
All events are time-boxed, so they have a maximum duration – the length of the time-box depends on the length of your Sprint.

The Sprint is essentially a container for all the other meetings and the development work. The other meetings provide opportunities to inspect and adapt the process.

 

 

Scrum process diagram

The Sprint

With a maximum time-box of one month, the Sprint is where the development work is completed, with the result being a “potentially shippable software increment”.

Potentially shippable means that the Product Owner may decide that the software can be released to the customer.
However, it doesn’t have to be released.

An increment is a small slice of software functionality, that can be added on to all the previously released increments.

But how do we know if the software is in a shippable state? That’s where “Done” comes in.

Scrum team members should have a shared understanding of what “Done” is, and this should also be shared between teams.

“Done” signifies when a Product Backlog item is complete.

 

Example Definition of Done

Each team will have its own definition, but here’s some examples of what you might include:

  • Code builds without errors
  • Code peer reviewed
  • Unit tests pass
  • User acceptance testing passed
  • Approved by Product Owner

As the Scrum Team progresses, it’s likely that the definition will become more strict.

 

The Sprint contains the Sprint Planning meeting, daily Scrums, development work, the Sprint Review and the Sprint Retrospective. There’s also the unofficial Backlog Refinement meeting which isn’t part of the Scrum Guide, but many teams find it useful to conduct.

No changes should be made during the Sprint that might endanger the Sprint Goal.

Sprint Goal

  • A high level objective for the Sprint that is met by implementing the Product Backlog Items.
  • The Team commits to the Sprint Goal rather than the PBIs.
  • The Sprint Goal provides guidance on why the Team are doing the work and allows flexibility around how the solution is achieved.

Also, quality goals should not decrease, although the scope of the sprint can be clarified and altered following discussion between the Product Owner and the Development Team.

Sprints last for a maximum of one month, but you may find it useful to use a shorter time-box. Shorter Sprints allow the team to more readily adapt to changing requirements, but make sure the Development Team has enough time to create software of value.

Shorter Sprints also reduce the risk if a Sprint is cancelled – the team has only ‘wasted’ the time in that Sprint and not any more. Additionally, they allow for more frequent inspection and adaptation, enabling the team to see more consistent progress towards a goal.

 

Cancelling a Sprint

Only the Product Owner has the authority to cancel a Sprint, but they can be influenced by stakeholders or the Development Team.
Cancellation usually occurs when the Sprint Goal becomes obsolete e.g. the feature is no longer required.

If the work that has been completed is in a shippable state, then the Product Owner can accept it. The rest of the work is put back into the Product Backlog.

 

A Sprint ends when the time-box expires and the following Sprint starts immediately (In practice this is usually the next working day).