7 Factors for running an effective Kanban Replenishment Meeting

In a blog post called Kanban Cadences, David Anderson laid out a set of 7 Kanban cadences or meetings that provide comprehensive opportunities for feedback, planning, and review in an enterprise. Some of these were already identified in his original blue book, Kanban: Successful Evolutionary Change for Your Technology Business, some were identified later and put together in this post.

Kanban CadencesImage Credits: Leankanban.com

As David said there, the Kanban Method doesn’t really propose 7 new meetings – it simply recognizes the need for these types of meetings that already happen in organizations today. However, by identifying them and calling them out, Kanban establishes the importance of implementing feedback loops at various levels of the organization, from strategic to operational, for achieving an effective flow of work throughout the organization so that it may deliver its products and services most effectively to its customers.

In my experience, 3 of these are critical for ensuring that a Kanban initiative gets off the ground successfully.  These are the Strategy Review (at least quarterly; provides overall direction to pretty much all organizational activity), the Replenishment/ Commitment Meeting (weekly/ bi-weekly; ensures alignment amongst all stakeholders and delivery teams on what to work on when) and the Standup Meeting (daily; probably the single most important interaction needed between team members to ensure that work on the Kanban board is proceeding smoothly and that the Kanban board is being used effectively).

In response to a recent customer request, I put down the seven key factors that teams need to consider for running an effective Replenishment/ Commitment Meeting. These are based on our own experience using Kanban for our own product development as well as that of many of our customers who have implemented this critical cadence.

I believe this may be of interest to other teams as well, hence this blog post.

1. A Clear understanding of the Replenishment Meeting Objective: Overall, the key objective of the Replenishment Meeting (RM) is to make sure the stakeholders and the team is shortlisting and selecting the right set work items to work on at any point of time. Depending on the context of the team, this might be very simple to very complex.

As an example, for a regular Help Desk or IT Ops team, I would imagine it would be a fairly simple task since their overall deliverable is pretty well defined and the prioritization of their work would be based on a combination of the urgent and the important. There are not too many ‘market or customer uncertainties’ for them.

On the other hand, for a product development team, where the market, revenue, competition, and technology risks and uncertainties are typically much higher, deciding which set of features to work on next would usually be a much more complex task.

2. The Replenishment Criteria: The criteria for pulling work on to the board (from backlog to Ready column) are – or can be – the most contentious part of the process. Depending on the number of stakeholders the team is supporting, the demands on them can be high and sometimes conflicting. The criteria for replenishment can be based on a number of factors – risk (or urgency, often reflected by SLA commitments, associated Class of Service or cost of delay – such as loss of a potential new customer should a new feature does not get developed), value or RoI expected (increase in revenue, market share, customer satisfaction, etc., or a simple Priority or Rank, usually defined jointly by the stakeholders, etc. The usual measures most teams use are probably the urgency and the priority.

Again, depending on your context, available information about new work items, and the strategic vs. operational nature of the work involved, you will need to select the appropriate replenishment criteria.

3. Replenishment Workflow: The process or workflow that is needed to ensure that the stakeholders get to an agreed set of criteria for work to be pulled is critical so that the team can unambiguously pull the right set of work during each replenishment meeting.

The process used for replenishment for different teams and contexts can be very different – and elaborate – and might need to be reflected either in a separate swim lane on the delivery team’s board – or could be a separate board altogether. In our own case, we expanded from a single column of our Dev team’s board to a separate swim lane to now a separate portfolio-style board where our entire backlog management and grooming process is reflected in 3 swim lanes, each of which represents different levels in a hierarchy of themes – epics and user stories.

Swiftkanban Board Hierarchy

In a physical board, you might get greater flexibility. In SwiftKanban, we have provided a few features to support some of this functionality – such as linking cards in a hierarchy, “transferring” cards from one board (planning) to another (execution), etc.

Also, once the team gets a better handle on the replenishment process itself, it can also look at using some of the “upstream kanban” capability such as abort/ discard analysis.

4. The Work Mix: Depending on the mix of the work the team handles, the replenishment criteria can be very different for different work items. When the team built its initial Kanban board, they would typically have done a “demand analysis” to understand their specific mix of work – and the Kanban board should already reflect it.

If the team has not already done it, it would also be beneficial to have them do a proper demand analysis – what kind of different work-items do they work on, what sort of requests do they get, do they have work items that can be classified under the various classes of services, etc. – and the replenishment process will need to reflect each of those classes of service as well.

5. Meeting Frequency: Depending on the nature of the work, and how quickly work traverses the board and the Ready column gets depleted, the frequency of replenishment would also vary. So, in our case, we do it once in 2 weeks. You might need to do it weekly or even daily – as might be the need for a Support/ Help Desk team. (In the getKanban game that you may have played in the Kanban training, the team has a policy of how often the board must be replenished – they do it daily as well.) So, you will need to decide on the frequency based on your context – especially how fast does the team keep running out of things to do!

A look at the current metrics of the team – especially the throughput chart and the cycle time distribution chart – will give them a good idea of what their typical board performance is and how often they need to meet for replenishment.

6. Collaborative Replenishment: A key success factor is to have all stakeholders who are impacted by the team’s work – or depend on it for their own work –participate in the meetings on a regular basis. Depending on the different customers or stakeholders a team supports, this can also be a contentious process. Too many – often conflicting – demands on the team can make it very challenging for everyone to come to an agreement on the exact set of work items to be pulled during each cycle.

In an organization such as ours, you would expect the replenishment meeting to be run by product management, with the dev team in attendance. However, we have other critical players who have an input into the process – support, sales, and marketing – all have valuable, sometimes business critical inputs to what has to have priority in the product. So our replenishment meetings have representation from these functions as well. But as you might imagine, we have had our own challenges about whom to give the highest priority during each replenishment meeting! We have even experimented with providing some capacity allocation to many of these functions so that both our product roadmap as well as critical customer requirements get a fair representation in the work that our dev teams do.

Depending on your team’s context, it is critical that all stakeholders needed for the replenishment meeting show up for each meeting. Getting them to show up is the first step towards starting effective replenishment meetings that ensure that your delivery team is clear about what it needs to work on next!

7. The Strategic Context: If you look at the various Kanban cadences (the 7 different meetings) – you might see the need for a higher level ‘direction-setting’ meeting – that sets the agenda or strategy for the team and provides a direct input to the replenishment meeting. This could be one of your existing monthly or quarterly planning or strategy meeting. Or you might want to institute a quarterly Strategy Review meeting if needed.

In our case, while we don’t have an exact replica of one of those 7, we do have a monthly ‘planning meeting’ and typically, a quarterly strategy meeting – all of which give us input into our product roadmap and marketing strategy and help us with replenishment meetings for our product board as well as our marketing kanban board.

Keeping these 7 factors in mind and preparing accordingly will help you tremendously in not only running your replenishment meetings well – but also having a happy set of people in your stakeholders and your delivery team!

What are some of your best practices for planning and running your Replenishment Meetings? I’d love to hear of your experience with running yours – and some do’s and don’ts for running them successfully!

Mahesh Singh
Co-founder, Sr. VP – Marketing

Share the Knowledge

LinkedIn
Facebook
X
Email
Pinterest
Print
Picture of Mahesh Singh

Mahesh Singh

Mahesh is a NimbleWork co-founder who hasn’t held a steady job for a long time and consequently, has run Product Management, Consulting, Professional Services and now the Marketing functions at NimbleWork. He is a Project Management and Kanban enthusiast and holds the Kanban Coaching Professional (KCP) and Accredited Kanban Trainer (AKT) certifications from Kanban University. Follow Mahesh on Twitter @maheshsingh

Simplifying Project Management!

Explore Nimble! Take a FREE 30 Day Trial

Other popular posts on Nimble!

Overview
Nimble Work Management
Overview

Share the Knowledge

LinkedIn
Facebook
X
Email
Pinterest
Print
Picture of Mahesh Singh

Mahesh Singh

Mahesh is a NimbleWork co-founder who hasn’t held a steady job for a long time and consequently, has run Product Management, Consulting, Professional Services and now the Marketing functions at NimbleWork. He is a Project Management and Kanban enthusiast and holds the Kanban Coaching Professional (KCP) and Accredited Kanban Trainer (AKT) certifications from Kanban University. Follow Mahesh on Twitter @maheshsingh

Simplifying Project Management!

Explore Nimble! Take a FREE 30 Day Trial

Other popular posts on Nimble!

We are on a Mission to
#HumanizeWork

Join 150,000+ Pioneers, Leaders & Mavericks receiving our updates!

Conduct Retrospectives

Subscribe To Our Newsletter

See Nimble Agile in Action!

Conduct Retrospectives

We are on a Mission to #HumanizeWork

Join 150,000+ Pioneers, Leaders & Mavericks receiving our updates!

Conduct Retrospectives