Scrum teams start every sprint by carefully planning and estimating its User Stories. They'll open the backlog and spend their allotted story points shopping for features they want to build. Libraries have been written about Story Points and Velocity, and certified consultants share arcane wisdom about rightsizing sprint commitment.
Planning such a timebox is a tricky balance between too few or too many tickets. Striking the exact right balance is very rare. At the end of the sprint, most teams just carry the leftovers over to the next one.
With iterative buffer planning, we turn that around. Rather than fretting to divine how many stories can fit in the allocated timebox, we ask the question: "What is the best solution to our problem that we can build in the coming weeks?" The team spends that time focusing on the problem. When the time is up, they move on to the next problem, knowing they've moved the needle a bit.
When teams start with this approach, they'll come up with way too many solutions they could build to address the problem. They will typically have more tickets than they can tackle. At the end of the first few Focus Blocks, they feel the urge to carry their tickets over to the next block. After all, their “sprint isn’t done”. It's a tough habit to unlearn.
But once teams get better at coming up with the best incremental solutions they can build within the given time, they'll experience another rite of passage: at a certain point, they will run out of tickets.
Let's say a team runs an e-commerce platform and wants to gather more user feedback after a sale. They decide to use their allocated two weeks to build a bespoke survey system. A few days after a customer buys something, a mail is sent asking them to fill out the questionnaire. The team gets cracking, and after seven days, their solution is ready. No more tickets are on the board, but there are still three days on the clock.
Coming from a Scrum-style hamster wheel, this can be a scary feeling. It's eerie how fast self-organizing teams revert to "What do we need to work on?" at the sight of an empty Kanban board.
But it's a valid question. What do we work on if we're done early solving out focused problem?
We could fix some bugs. We could start the following Recovery Block a bit earlier to get a headstart on operational work. We could give everyone three days off and still be on schedule! But that defeats the point of Focus Blocks.
When we plan focus blocks to address a problem, we define our appetite. "This problem is so important to us that we will dedicate three weeks of our attention to it". Being early with our first solution doesn't mean our appetite has gone down. It just means there is room to build an even better solution!
If the team were still in the situation of having too many tickets on the board, they wouldn't hesitate for a second to start building the next iteration to address the same problem. After all, there is more work to do. But now that the board is empty, they feel like they're done and should urgently move on to other things to remain productive. Old habits die hard.
When a team has built a solution that addresses the problem and still has some time on the clock, they should ask that same question again. Given the new state of the product and the time that's still left in this focus block, what is the best we can build to move the needle even further?
The team in the example above could build a chain of reminder emails for those who didn't complete their surveys. They could build an insights dashboard with the results of that user feedback. They could make the questions configurable, allowing business stakeholders to experiment.
There are a thousand ways they could improve the product to address the problem even further.
Software teams often complain about the hamster wheel and the general lack of time to build things the right way. That’s a valid concern for those who want to build great products. When teams get better at iterative buffer planning, they find themselves in a position where they do have the time to build something better.
It would be crazy not to do that.
So, rather than fixing some bugs or trying to get ahead of schedule, keep addressing the problem until the time runs out.
We can always build a slightly better solution.