Sprint planning
As the Scrum Guide says “Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.”
- 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 purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.”
- 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 number 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 “The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities.”
- 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. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
- 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 purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved. The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.”
- 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 breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.”
- 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.