Replenishment ceremony — a better way to plan

Using flow metrics and just-in-time commitment to improve planning ceremonies.

Planning. A necessary evil in software development. What to work on, how long will it take? Teams often answer these questions through lengthy planning sessions (has anyone spent a full day on Sprint planning? I certainly did multiple times, and it wasn't fun), planning poker, t-shirt sizing, and many other techniques that rarely produce good results.

There is a much simpler and better alternative, one that uses ‘just-in-time’ prioritisation and ‘just-in-time’ commitment. I’ve used and believe in the ‘replenishment ceremony’ for years. It is a much better way to plan for short horizons. It uses less time than traditional planning ceremonies and produces more predictable results.

While the technique has been around for a while, being defined by Dan Vacanti in his great ‘Actionable Agile Metrics For Predictability: An Introduction’ book, it is largely unknown.

What is it? How do we make it operational? Read on. Try it. Done well, you will find process improvements by saving time and improving the accuracy of your commitments.

What is a replenishment session?

• A way to bring in work-in-progress work items from the collection of idle, backlog items
• These items become committed work
• For those who’ve used Scrum, this is similar (but not identical) to ‘sprint planning’ sessions

During replenishment sessions, we bring items typically from the backlog into work-in-progress

What happens in the meeting?

• The session emphasises the use of ‘just in time’ (JIT) prioritisation and ‘just in time’ commitment principles
• These principles focus on two questions: ‘right thing’ (JIT-prioritisation) and ‘right size’ (JIT-commitment) questions
• The ‘right thing’ question focuses on identifying the right work item to work on. To make it effective, the backlog should be somewhat organized so the pool of potential work items is not very large. Having a ‘Story map’ readily available is a great way to help answer this question.
• The ‘right size’ question focuses on identifying if the size of the item is ‘right’

During these sessions, we focus on ‘just-in-time’ prioritisation and ‘just-in-time commitment

What is the ‘right size’ and the SLA?

• Choose the level of confidence level you’d wish to apply to the question — typically choose between 85% or 95% (but other values can be used)
• Use historical cycle time data and identify the cycle time of the confidence levels you’ve chosen
• Present the work item to the team. Explain it. Then, using the Cycle time for the chosen confidence level, and ask the team if they can build it up to that cycle time.
• This confidence level becomes the SLA—the team's commitment to do everything in their power to complete the work item within the selected cycle time.
• For instance, if you chose 85% confidence levels and your 85% cycle time was 15 days, then the question becomes, ' Looking at this item we’ve selected, can we build it in up to 15 days?’
• If the answer is ‘yes’, bring the work into the system
• If the answer is ‘no’, then further discuss. See why the answer is no and try to find solutions to bring this to a level where the team can commit to the selected SLA. Often the item is too large — if this is the case, split it during the session.
• Other times, there is a dependency that extends the time, and in this case, consider leaving it in the backlog until next time (but you will need to find a way to chase the dependant partner). If nothing else can be done, we accept that the work item could become an outlier and knowingly bring it in, but we will pay careful attention while the item is work in progress

The JIT prioritisation and commitments are achieved by finding the ‘right thing to work’ and by answering the ‘right size’ question

How many items to select?

• To answer this question, we aim to achieve a ‘preservation of flow’ — to protect against artificially increasing cycle time (since we know, based on Little’s law, that cycle time increases with larger work-in-progress items) if throughput cannot be increased. We strongly wish to avoid increasing cycle time.
• The ‘preservation of flow’ is the principle of matching the arrival rate of work with the departure (measured as ‘throughput’)
• So, if the recent team throughout is 10 items/week and the replenishment is weekly, then aim to leave the replenishment session with 10 items in your system’s committed queue (e.g., Next). If, for instance, there were 5 items in this column, then bring only 5 new items.
• The way we do this is to select a ‘Work in progress limiter’ on the replenishment queue (e.g. the Next) to match the achieved recent throughput (10 in our example)

We aim to avoid artificially increasing the cycle time and focus on preserving the flow

What is the frequency?

• Weekly seems to be a good cadence, making sure that you use the right throughput period in the ‘preservation of flow’
• It can also be done ad-hoc

How should it feel?

• From a relative perceived effort (RPE) scale of 1–10, where 10 is the hardest, these sessions should be somewhat hard, a 6 or 7.
• They shouldn’t be simply treated as admin work — stories need to be explained, designed, prepared in elaboration, reviewed, etc

I found that this simple technique can improve the system's predictability because it links a commitment to data (cycle time). It also protects the system’s work-in-progress limits (by having a WIP limiter as a constraint). And bring the concept of commitment, something that at times we forget, to the fore. Try it out, and let me know how it goes.

If you wish to learn more about the flow metrics of cycle time, work in progress count and throughput, check out this blog https://medium.com/better-programming/its-mostly-about-the-flow-a-journey-of-transformation-f665419121a7