There is a mass of literature about how, how much, and how often teams should plan. Most people recognise that we should avoid the extremes of overly heavy processes (the Sin of Waterfall) and the anarchy of pseudo-Agile, which often manifests itself as “hey, Agile means you don’t have to write anything down!”.

The most commonly used pattern that is meant to guide teams between these two extremes is that of Scrum, which mandates a single, two-hour Sprint Planning meeting, once per sprint, which produces in one go the correct amount of planned work for the whole team, which would be 100 man-days of work for a 10-person team (all of these figures presume a two-week length sprint).

In practice there is a large amount of unavoidable variability in the execution of a block of 100 man-days of effort, and work is constantly being discovered or reprioritised during the course of the sprint, meaning that the output of a single Sprint Planning meeting at sprint start is often wholly inadequate for the rest of the iteration.

The better, alternative approach is to apply to planning the same principles that almost all software development teams already apply to deploying – that it is best done little and often. You need to be able to decide on any given day whether you have planned enough, or need to plan some more (possibly that very day), and the good news is that a well-functioning Agile Board is constantly giving you this information, if you know where to look.

The key concept is that there is a status – in software development teams usually called Ready for Dev, aka Ready to Start – which represents a buffer state between the end of the planning/preparation process, and before the start of the delivery/execution phase. This column holds your stock of planned work.

So how much stock should you keep? Well, it is possible to plan too much, and to plan too little, and between those extremes lies the Goldilocks Zone where you have planned the right amount.

The problem with planning too little – ie there is a small number, or even zero tickets in Ready for Dev – is hopefully clear; the delivery part of your pipeline will be starved of fuel, and will grind to a halt. Yes, you can do some emergency planning there and then, but this is an inefficient and stressful way to work.

Less obviously, it is also possible to plan too much. Perhaps it is tempting to get 100 tickets to Ready for Dev, and then you won’t have to do any more planning for six months? The problem here is that planning has a shelf-life; all plans are predicated on assumptions about the state of the overall codebase, the product and the company at the moment delivery starts. If the gap between planning and execution is small, these assumptions are more likely to be correct.

But if that gap is large – say you plan a piece of work now but don’t start it for a year – it’s very likely to need replanning from scratch (eg because the tech landscape has completely changed) or to be thrown away entirely (eg because that feature is no longer a priority). So you invested a large amount of time and effort in that huge planning exercise, and in the end most of it was waste – that is the consequence of planning too much.

So how do we get to the Goldilocks Zone where we constantly have the right amount planned? This amount is contextual – it varies for every team – but the principles are universal.

Begin by picking an approximate period of time for which you want a stock of already-planned tickets. You might for example want “planning” to be 2-3 days ahead of “delivery”, meaning that if you stopped all planning activities immediately, it would be 2-3 days before Ready for Dev runs out of tickets.

How do you know what period of time is appropriate to pick? That depends on the availability of the people who do the planning. If the people required for planning are all highly available (ideally, co-located) people who are dedicated to this one team, they should be able to switch to planning activities at very short notice (ie they can plan on the same day a deficit is noted). This setup requires a smaller buffer of planned work. Different setups need a bigger buffer to make up for the extra time it will take to get new planning scheduled.

This period of time then needs to be translated into a desired number of planned tickets. Here the main factor is team throughput; the quicker your team gets through tickets, the more you need in your Ready for Dev buffer, so if a team gets through 3 tickets a day and you want a 3-day buffer, that’s 9 tickets.

This calculation works fine if your team is very cross-functional, meaning anybody can pick up any ticket, but if you have specialists on the team who can only work on specific kinds of tickets, you will need to factor that in, and ensure that each separate specialism has enough of their kind of tickets in Ready for Dev.

Having thus calculated an approximate target for ‘planned tickets’, the deciding factor – as ever – is experience. If you observe a team’s Agile Board regularly over a small number of weeks, it should become clear what the right number of tickets in Ready for Dev is for that team.

Teams applying this method may end up cancelling all regular planning sessions; instead they decide during each morning’s Stand-up meeting whether or not a planning session is needed for later that day. This is a truly Lean/Agile team, where processes have become highly dynamic and responsive, and ‘rolling wave’ planning has been truly implemented.

Rolling wave planning can apply at the strategic level too. Just as a delivery team can get its planning down to a snappy half-hour meeting every other day or so, a company can get its detailed roadmap planning down from six-monthly or quarterly (which is often regarded as a triumph) down to something closer to a monthly rolling wave. The same preconditions – an accurate portfolio-level Agile Board, and good availability from the planning resources – are of course also needed to achieve this goal, which produces the same rewards of more responsiveness and less waste.