The Scrum guide clearly depicts the meetings that all Scrum teams must hold and when. But there is no guide of mandatory meetings for Kanban. Kanban teams do what makes sense for their respective team. And no two teams need to be exactly alike. Since Kanban is about reducing waste, it is important to note that unnecessary meetings are a huge waste. Moreover, painful meetings can affect the morale of the team.
On the other hand, meetings that provide value to the team are important. But they should be performed at the times and with the intent most valuable to the team. Here is a quick reference to what meetings in Scrum will never happen on a Kanban team and which will likely be replaced with something else.
|Scrum teams typically do||Kanban teams typically replace with|
|Sprint Planning||No meeting (no sprints, typically no sizing)|
|Daily meeting and periodic planning meetings if necessary|
|Daily Scrum||Daily meeting|
|Retrospectives||Team interactions meetings|
|Kanban Metrics meetings|
|Sprint Review||Periodic demo’s if not frequently deploying or if necessary in order to get product feedback from stakeholders|
|Product Backlog Refinement||TBD|
no sprint planning meetings
Sprint Planning meetings occur at the beginning of every sprint on a Scrum team in order to forecast what items the team will complete during the next 2 weeks. Since there are no timeboxed sprints in Kanban, this meeting obviously goes away. This saves a lot of time on Kanban teams as Scrum teams will often spend half a day every 2 weeks forecasting and planning their upcoming work. This is not to say that there is no planning on a Kanban team. Some teams will do very little planning while others may need more discussion. Often, planning discussions can typically happen briefly during the Kanban team’s daily meeting. But if a team requires more detailed planning then periodic planning meetings will occur with a frequency and duration based on the needs of the team.
The daily scrum is often replaced with a daily meeting in Kanban. These meetings may appear to be identical on the onset. However, a scrum team’s daily meeting often turns into rote status with all team members discussing what they worked on. Kanban teams focus on flow of the visual board and address things like bottlenecks.
team interactions meetings
Retrospectives often still periodically occur on Kanban teams. However, retrospectives are always backwards looking reflecting on how the team has been doing and what changes are important going forward. While this is important, it is equally if not more important for teams to focus on establishing good communications and teamwork from the onset of the teams forming. So, calling these meetings team interactions meetings seems more appropriate than retrospectives and holding them from the start of teams forming is absolutely critical. The frequency of holding these meetings is based on the needs and maturity of the team. Details of team interactions meetings can be found on my other blog, https://kanbanmentor.com/team-interactions-meetings/.
Kanban metrics meetings
Periodic Kanban metrics meetings should be held by the team to look at and discuss trends surrounding metrics such as throughput and cycle times. During these meetings, the team can discuss how to optimize and improve. Often times, these discussions are happening as a natural occurrence during the daily meeting. So, once again, the frequency and duration of these meetings will depend on the team. This is also the subject of a future blog.
no sprint reviews
The sprint review on a scrum team does not happen on Kanban teams. This again saves lots of time. Having said that, if the team is not frequently deploying and if the team is not already getting continuous feedback from their stakeholders in other ways, then a periodic demo in order to obtain this feedback may be necessary.
product backlog refinement
Product backlog refinement is again a topic that likely requires its own blog and is extremely dependent on the team. Some Kanban teams contain a role similar to Scrum teams known as the Product Owner. This is a person responsible for what the team works on and prioritization. Essentially this person maintains the To Do column on the Kanban board. Other teams may hold periodic team meetings to discuss requirements as a team creating their own To Do column. Moreover, some teams will keep requirements extremely terse while others may write more formalized user stories with associated acceptance criteria. Teams that create user stories may also create larger user stories (or Epics) which need to periodically be refined. Since there is such a wide range of options, the Product Backlog Refinement meeting may not happen at all on some Kanban teams or they may be replaced by something else on others. This is hugely dependent on how the team operates.
do what makes sense for your team
The bottom line is to only hold meetings that are absolutely necessary and deemed valuable by the team. It is important to note that the need for meetings may and likely will change over time. For example, a team may hold periodic team interaction meetings every 2 weeks in the beginning but as the team matures, the team may decide that once per quarter serves their needs. Meetings should always be on the radar of a team’s relentless pursuit of removing waste.