Scrum has four ceremonies that bring structure to each sprint:
- Sprint planning: A team planning meeting that determines what to complete in the coming sprint.
- Daily stand-up: Also known as a daily scrum, a 15-minute mini-meeting for the software team to sync.
- Sprint demo: A sharing meeting where the team shows what they’ve shipped in that sprint.
- Sprint retrospective: A review of what did and didn’t go well with actions to make the next sprint better.
The purpose of the Sprint Planning ceremony is to set up the entire team for success throughout the sprint.
The required participants are:
- Development Team
- Product Owner
The sprint planning happens just before the sprint begins and usually lasts one to two hours.
Coming into the meeting, the product owner will have a prioritized list of the product backlog items. The product owner discusses each item or user story with the development team, and the group collectively estimates the effort involved. The development team will then make a sprint forecast, normally based on the team’s velocity, outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog.
Does Kanban have a Sprint Planning Ceremony?
Yes, Kanban teams also plan, but they are not on a fixed iteration schedule with formal sprint planning.
Sprint Planning and Story Refinement
Some organizations use the sprint planning meeting to flesh out the details of each user story. In fact, it is highly encouraged that all participants engage in effective discussions so as to ensure everyone understands the scope of the work.
Other organizations have a separate Story Refinement sessions where they discuss the details of each story along with a rough estimate of how much work is involved in delivering the stories. Normally stories are broken down into a number of small tasks.
By having these separate story refinement sessions, typically in advance of the next sprint, the sprint planning session becomes shorter in duration and is aimed at only accepting stories into the upcoming sprint.
The daily stand-up meeting is designed to quickly inform everyone of what’s going on across the team. It is not supposed to be a detailed status meeting. The tone should be light and fun, but informative. Have each team member answer the following questions:
- What did I complete yesterday?
- What will I work on today?
- Am I blocked by anything?
The daily stand-up occurs once a day, normally in the morning and requires the development team, ScrumMaster, and Product Owner to attend. It is advised that the duration is no more than 15 minutes, hence the purpose of standing up to keep the meeting short.
One of the advantages of the daily stand-up meeting is that it makes the individuals be true to themselves. There’s an implicit accountability in reporting what work you completed yesterday in front of your peers. No one wants to be the team member who is constantly doing the same thing and not making progress.
Distributed teams typically use video conferencing or group chat to close the distance gap.
At the end of the sprint, each team gets to demo or showcase their newly developed features or just generally what they worked on during the sprint.
This is the time for the team to celebrate their accomplishments, demonstrate work finished within the iteration, and get immediate feedback from project stakeholders.
The duration can vary on the number of items to showcase per team.
The work is usually showcased to participants of the respective team, namely the development team, ScrumMaster, and Product Owner as well as other teams and project stakeholders. For the demo to be of any value and interest to others, the work should be fully demonstrable and meet the team’s quality bar to be considered complete and ready to showcase in the review.
Is Product Demo applicable to Kanban?
Like planning, review for Kanban teams should be aligned with team milestones rather than on a fixed cadence.
And finally on to the sprint retrospective which occurs at the end of the sprint, typically after the sprint demo and lasts about one hour. Participants are the development team, ScrumMaster, and Product Owner.
Agile is about continuous improvement and getting rapid feedback to make the product and development culture better. Retrospectives help the team understand what worked well–and what didn’t. Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that.
Sprint retrospectives shouldn’t be just for making complaints without taking action. Retrospectives are a means to identify what’s working so the team can continue to focus on those areas and also what’s not working so the team can discuss and collaborate to find creative solutions to the problems.
Does Kanban also have Sprint Retrospective?
Scrum teams do sprint retrospective based on a fixed cadence. Nothing stops Kanban teams to benefit from occasional retrospectives, too.