The Sprint Goal…..

• Is an objective set for the Sprint that can be met through the implementation of Product Backlog.

• Provides guidance and focus to the Development Team on why it is building the Increment

• Gives the Development Team some flexibility regarding the functionality implemented within the Sprint.

• Is useful in the sprint review to help convey to stakeholders work classed as done in the sprint

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Scrum Guide

For how the sprint goal is structured, one approach that teams find useful is to have a user story so that in the sprint review we have something that stakeholders can relate to and that can be demoted from a users perspective.

Dangers of a Status Meeting

• End up with a project manager type role and people reporting updates. This is normally the PO or scrum master

• Loses meaning - inspection and adaption becomes monitoring and being told what to do

Why do the daily Scrum?

“Daily Scrum optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work”

Scrum Guide

What is the daily Scrum For?

“The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.”

Scrum Guide

Sprint Goal

Once the sprint goal is set, nothing is done to endanger it. Once the sprint begins, no one, no one tells the development team what to do. What the product owner can do however is clarify and re-negotiate the scope as more is learnt.

The suggested questions in the Scrum guide for the daily scrum are orientated around the sprint goal

• What did I do yesterday that helped the Development Team meet the Sprint Goal?

• What will I do today to help the Development Team meet the Sprint Goal?

• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

A lot of teams will explore this further and include things such as

• Avalaibitly to help with pairing with other team members

• Support/monitoring updates

• Inspecting and adapting the sprint plan - e.g. changes to who is doing what or picking up the next ticket from

• If people are stuck, need help or advice

• Chasing code reviews

• Informing other team members they have questions e.g. need to check how the UI will work or I need to ask the PO questions to further clarify the requirements

https://www.mountaingoatsoftware.com/blog/what-are-story-points

During the sprint…

No changes are made that would endanger the Sprint Goal.

Quality goals do not decrease.

Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

So what happens about support?

Scrum doesn't define how to deal with support but it does say that scope may be clarified and re-negotiated however this increases multi-tasking and can affect the sprint goal. If the sprint goal becomes obsolete then the sprint can even be cancelled

Cancelling a sprint…

Only the Product Ownder has authority to cancel the sprint

Can be done is the sprint goal becomes obsolete or no longer makes sense given the circumstances

Can be trumatic to the Scrum Team

Support

Scrum uses empirical process control, so we can look at what has been done in the past to predict the future.

We use this approach when looking at how much the product development team can commit to in sprint planning.

For example, in the diagram below, the last 3 sprints the team has managed to complete the following number of story points

• 550 SP

• 670 SP

• 450 SP

So taking an average, perhaps for the next sprint, the team should only commit to around 550 SP.

The amount of support a team gets is not always that predictable, but we can use the same approach to planning.

Looking at the diagram above, we can see there are some blue splodges added to the work completed columns. These represent support that was added to the sprint as Product Owners decided that the team must look at these issues and add them to the sprint.

Over the last 3sprints, let’s assume the support issues have added

• 8 SP

• 12 SP

• 9 SP

So our support average is 9 SPs per sprint.

Planning for Next Sprint

So for the next sprint, we could assume

• Our average velocity is 550 SP

• Our average support velocity is 9 SP

So we should only allocate to the sprint backlog 540 SP to allow for possible support to enter the sprint.

However, this system will only work if teams understand that any work done within a sprint must be tracked - many teams create specific ticket types e.g. a live defect so it's easier to see support data over time