1- Iteration kickoff meeting
The Iteration kickoff meeting is typically a two-part meeting on the last day of the sprint with the objective of clarifying the roadmap and planning the upcoming sprint.
Product Backlog review
The first part of this meeting consists of a review of the product backlog, between the team and the Product owner, so that he can communicate to the team the most important upcoming items and what he would like to be done during the next sprint.
This is the occasion for the team to ask questions to the Product Owner and request clarification of the items in the Product backlog, when necessary. By the end of the Backlog review, the team will be able to choose a theme for the next sprint: one phrase that describes the goal of the sprint.
Planning & Kickoff
During this second part of the Iteration Kickoff, the team picks the user-stories to be completed during the sprint, decomposing items into tasks and estimating them in hours. If the Product Owner is not present during this part of the meeting, he must make himself available to answer specific questions and sometimes negotiate with the team when an Item is judged to be too big or its estimation significantly differs.
The objective of here is to build the Current Iteration Backlog.
A good rule of thumb is to calculate 2 hours for each week of the sprint. A 2-week sprint kickoff will last 4 hours, a 4-week sprint kickoff, 8 hours, etc.
2- Daily Stand-up Meeting
As the name points out, the Daily Stand-up Meeting is a meeting that is held on a daily basis. The objective of a stand-up meeting is to provide a status and progress update to the rest of the team.
These meetings are held in at the same place and same time every day and should last no more than 15 minutes. Standing up usually enforces that rule.
During the stand-up meeting, each team member is encouraged to answer three questions:
- What was done yesterday;
- What will be done today;
- Am I blocked or do I foresee any Impediments.
Daily stand-up meetings are an efficient way to track if the team is able to fulfill its commitment. Every team member is required but the meeting is never delayed if someone is late.
Daily stand-ups are meant as a way for the team to be in sync, not an occasion to enter into deep discussions about technical issues.
3- Iteration Review & Retrospective
Similar to a post-mortem at the end of a project, the Iteration Review and Retrospective is the moment to present what has been achieved in the last iteration. Success criterias should be reviewed to determine if success was achieved. Allow each team member to present and demonstrate the functionality that was added during the last iteration.
Sprint (or customer) Review
Iteration reviews should be told like a story of what can now be accomplished with the functionality added during the sprint. When picking user stories, there is usually a theme around them. A sprint review that is meaningful usually has some of these characteristics:
- A theme that speaks to everyone and that is engaging to the team;
- Include a review of the team's commitment;
- Review of key decisions made during the sprint;
- Demo the work completed like a story, a sequence of events that the end user will do;
- The review should be compelling to the team - bring pizza or donuts if you need to;
- Include a review of the upcoming priorities;
- Should not be too technical;
- Should allow to gather feedback;
- Get customer acceptance, if applicable.
As you get used to it, the teams will get better at delivering these stories and present them in a way that is compelling.
Sprint review meetings are variable in length depending on sprint length and team size. Shorter reviews are typically seen in teams developing a product for their company. Longer reviews are often necessary when the team is part of an Agency developing a product for a customer.
A good rule of thumb is to calculate 30 minutes for each week of the sprint. A 2-week sprint review will last 1 hours, a 4-week sprint review, 2 hours, etc.
Team retrospective meeting
The Team Retrospective meeting allows the team to look for ways to improve both the product and the process. It's the perfect moment to get together as a team, face what went well and what didn't and ask ourselves these questions:
- What went well and how can we reproduce it in future iterations?
- What did not go well and how do we avoid it in future iterations?
- Should anything be added to the backlog?
- Are there foreseeable roadblocks in the future?
This meeting is often over looked, but is a critical of the scrum meeting but is the scrum team equivalent to a spring-cleaning: throw away the bad which leaves room to fill with new and better stuff. It is the time to bring up bad habits and break them.
An effective retrospective meeting should last about 30-45 minutes for each week of the sprint.