Essential Items

• The Product Development Team

• The PO

• The SM

• Snacks

• Tea / Hot Chocolate

Structure

• PO Update

• Definition of Done (D.O.D)

• Velocity

• Proposed Sprint Backlog

• Sprint Goal

PO Update

This is the kickoff for the meeting and starts with the PO setting the scene.

• 10 mins max

• Feedback from stakeholders - e.g. How the product is doing, discussions with them, support issues

• Updates on the roadmap if anything has changed or how we are doing

• Whishes and desires for this sprint - This is a big hint and useful to give ideas about the sprint goal

• Allow members of the product development team to ask any questions around the bigger picture or the product, vision etc

Definition of Done (D.O.D)

This section is used to clarify with the team exactly what they consider done to be. It is important to discuss what done means as if it changes it might affect how much work the team can bring into the sprint. I normally do this by asking each team member what items are on the D.O.D list until they agree all items have been listed.

The result is the whole team (Product Owner, Product Development Team and Scrum Master) all agree on what done is so when tickets are moved to the done column, everyone knows what this means.

Velocity

The goal of this section is to agree roughly on how much the team can commit to and normally follows this format

• Close the current sprint in front of the team so they see items completed and leftovers and the burndown.

• Open up the velocity chart so the whole team can see the teams velocity

• Calculate an average from the last few sprints - 3 is normally enough

• Check for holidays, training or other events that may take members away from the sprint as a result, the velocity needs to be adjusted

• Agree on an estimated number of story points to aim for the sprint being currently planned

The outcome of this section is to have a rough number for looking at the proposed sprint backlog.

Proposed Sprint Backlog

The first part of this section involves

• Identifying the leftovers from the last sprint

• The PO and the team deciding if the leftover item should be added into the next sprint and if so,

• Estimating again the amount of effort and adding the issue into the sprint by dragging the item from the backlog into the proposed sprint backlog

After all the leftovers have been discussed, the next section is to look at the top of the backlog that is ready for planning and for each

• PO read the story out loud to other members of the team

• Any assumptions?

• Any dependencies?

• Check the acceptance criteria, if there is none, write it there and then with the team.

• Allow the product development team to discuss how to implement the item

• Discuss the issue

• Ask the question “Does everyone understand the issue, does anyone have any questions”

• If the issue has not been estimated - estimate the issue

• If the issue has already been estimated, estimate again if there has been substantial discussion around how the implementation will work or confirm the team are happy with the current estimate.

After the issue has been discussed, the PO can drag the issue into the proposed sprint backlog. This process will carry on until the number of story points roughly matches the amount discussed during the velocity section.

Commitment (Now called Forcast)

When the proposed sprint backlog is full, the team and the PO need to take a moment to consider what has been added. If the PO wants to add more then they need to negotiate with the team either by removing some items already added or if the team feel comfortable to take on more.

During this time its useful to

• Make sure the highest priorities are at the top of the sprint backlog

• Encourage the team to think about their plan of attack for the sprint and allow them to discuss it.

• Make this visual so the entire team is looking and viewing the proposed sprint backlog

• Allow them to focus in silence if need be, ask prompting questions “How do you feel about this” - challenges are ok!

Once agreed, the final thing left is the Sprint Goal

Sprint Goal

The idea of the sprint goal is to provide focus to the team during the sprint and act as a constant reminder about what they are working towards.

The initial idea of a sprint goal comes from the PO update however the sprint goal should come from the team itself using a consensus-driven approach.

Once a goal has been decided by the team, to double check if the goal is realistic, the team can vote on how they feel about it by simply raising a hand and

• Thumbs up for its a good and achievable sprint goal

• Thumbs halfway - not sure or a bit nervous that the goal is more of a stretched goal

• Thumbs down - Sprint goal is too difficult or ridiculous - in this case, the team should revisit the sprint goal and then vote again.

Print the goal, stick it on the wall, GO GO GO!