Events – good practices

Sprint planning

As the Scrum Guide says “The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. Sprint Planning answers the following: What can be delivered in the Increment resulting from the upcoming Sprint? And, how will the work needed to deliver the Increment be achieved?”

  • The Sprint Planning is planned directly at the start of the Sprint and sufficient for it has been planned
  • The PO has prepared a proposal for a sprint goal and a prioritized list of sufficiently refined stories (backlog ready). Where helpful, the PO can explain how the goal and stories fit the higher level plan: features, objectives, milestones.
  • The whole Scrum team is there: Dev Team, PO, SM, and has a clear overview of availability during the sprint.
  • Team velocity is based on yesterday’s weather (3 last sprints) and has been adjusted for availability of team members and other circumstances.
  • Stories are clear, agreed and properly estimated by the development team. Stories should be small enough in both effort and duration to easily fit the Sprint (preferably about 10% of your velocity).
  • The Sprint Plan is checked for availability of specific competences, dependencies outside the team, and risks. Also, for any other time consuming activities (like on-boarding, moving, department meeting, etc.)
  • The Sprint Plan includes at least one improvement action.
  • There is an agreed interrupt buffer to cover unforeseen urgent and important work. There is an agreed amount of time planned for technical debt. The development team members do not have ‘secret missions’ (working on something else).
  • The team has not over-planned the Sprint (we aim to finish early).
  • The entire Scrum team is aligned and agrees on the Sprint goal
  • The Development team commits to the plan for the Sprint. The Sprint board is created reflecting all work, sprint goal, burn-down chart and active risks/blockers

Daily Scrum

As the Scrum Guide says “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. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.”

  • The Daily Scrum is planned at the same place and time every day and all development team members are there. PO, SM and others may attend but not participate unless requested by the development team.
  • All are prepared to keep the event under 15 minutes and useful. This means that each Dev team member is ready to share progress towards Sprint goal, plans for the next 24 hours and blockers/risks, and has updated the Sprint board. Any uncertainties (like achieving Sprint goal, changing or adding new stories) were already discussed with the PO or are part of the plan for the next 24 hours to do so.
  • The team guards from adding work and scope creep/gold-plating by either PO or themselves, and offer/request help from each other.
  • The amount of stories in progress is below the WIP limit or part of the plan for the next 24 hours is to get it back under. Fixing bugs resulting from ongoing work should be part of the plan for the next 24 hours.
  • The development team guards the usage of the buffer (spread across Sprint). Any interrupt work should be agreed with the PO for urgency and importance.
  • At the end of the event, the development team has an agreed plan for the next 24 hours.

Sprint Review

As the Scrum Guide says “A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.”

  • Sufficient time has been planned for the event and the whole Scrum team is there.
  • The PO has invited stakeholders and has prepared the event: a list of all stories considered done and all stories not finished + Sprint goal achieved y/n, an overview for long term progress (features / objectives / milestones)
  • The development team has prepared demo(s) to show the done work, if feasible, on an integrated system. It should be understandable and interesting for stakeholders.
  • During the event, feedback is received from stakeholders and attendees have collaborated upon next things that can be done (upcoming Sprint or later). After the event, the PO adjusts the backlog if needed.

Sprint Retrospective

As the Scrum Guide says “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.”

  • Takes place after the Sprint Review has been completed. Sufficient time has been planned for the event and the whole Scrum team is there.
  • No one outside the Scrum team is allowed to join. All feel safe to share information and the event is in a ‘safe environment’ (not in the open). Agreed by all that ‘what was said in the room, stays in the room!’. Minutes are not shared outside the team.
  • The SM has:
    • prepared an agenda and approach (e.g. Tops/Tips/Actions, improvement brainstorm, blow-off-steam session, beer-and-wine session, …). The approach is not the same every time…
    • collected data during the sprint and is ready to share it with the team (e.g. occurrences/behaviors, metrics like interrupt buffer usage, team happiness, burn-down, delivery rate % and quality, etc.).
    • an update on the committed improvement action(s) from this Sprint
  • The Scrum team identifies at least one SMART improvement action to be completed in the next Sprint. The session is not used for ‘whining’ only. All team members had a chance to do their say (no bullying) and actively joined. The result of the Sprint Retrospective contributes to a positive result for the team (trust, confidence, self-esteem, motivation, velocity, etc.).

Backlog Refinement

As the Scrum Guide says “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. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.”

  • Sufficient time has been taken into account for Refinement. If helpful, dedicated time block(s) have been planned
  • The PO has invited any required stakeholders and has an agenda which mainly consists of a prioritized list of features and stories to be refined in this session. There should be a healthy mix of planning horizons: next sprint, sprints close by, and future.
  • The PO has prepared the features and stories to be refined. They have been pre-discussed with stakeholders for value and checked if they fit the why, vision, and objectives. It helps to already think in terms of how it can be demonstrated/verified (Behavior / test driven, acceptance criteria).
  • During the event, features and stories are being clarified, further discussed and detailed, split/sliced (if needed), and estimated on effort. Clarity, details and accuracy of effort grow with each refinement until the team agrees it is ready to be planned, and may need to be revised if circumstances (like stakeholder needs) change. It helps to use a template.
  • Exceptionally, ‘spikes’ are defined (a quick investigation, analysis, test. …). For example, when specific competences are required the team does not (yet) have, technical risks / uncertainties, dependencies outside the team, etc.