As you know, scrumban is based on planning on demand. The buffer triggers planning, once the backlog is empty, and guarantees that there is still work remaining to be done by the team in the meanwhile. However, by definition this planning focuses solely on the next best thing for the team to work on, simply disregarding any other planning as having no value. Therefore in this way only the most immediate plans are made, while anything not in the nearest future is forgotten.
For some teams and especially the ones that want to follow their long-term plans while still applying scrumban, this is not ideal. That is why long-term planning is being introduced in the form of bucket size planning. Instead of looking for the next best thing to work on, it focuses on the future projects. Bucket size planning works in a simple way – the team is moving future projects through four different buckets (you can call them lists, boards, or anything else that fits your process).
- 1 year bucket. It is the first in the bucket size planning. It is here that the team starts to plan the future projects and store their ideas, goals and large plans. Looking at the items in this bucket, you should see the company’s roadmap for the future, however the ideas are not detailed at this point.
- 6 months bucket. Once you have decided to move forward with a plan, it is moved over to this bucket and made more detailed. Looking at the items in this bucket, should give a more detailed idea of what you want to achieve, while still not specifying every detail. The perfect example of items in this bucket, would be scrum epics.
- 3 months bucket. Again, after deciding to go forward with a specific epic, it is moved over to the 3 months bucket. Once in this bucket, the item needs to become more defined – it would be like splitting the epic into user stories and defining what and why you want to achieve.
- Current bucket. Lastly, the items are moved into this bucket, bringing them the closest to being taken on by the team. The items are broken down into clear tasks, just like user stories are broken into tasks in scrum. And once the team is ready (on demand planning is triggered), these tasks are moved into the project backlog.
It is worth to mention, that the bucket names have nothing to do with the duration of the tasks or the deadlines, they are simply representing the stage of progress from idea to completion. You can chose to rename the buckets to better represent your process and also add more of them, if you feel like you need to.
It is suggested to do the bucket size planning every 6 weeks, however, this may not be necessary and the reoccurrence of planning should be defined by your process. While having scheduled planning does contradict with the on demand approach, it allows for the teams to keep an eye on what projects are coming in the future. At the same time, the long-term planning meetings can reoccur rarely this way not having an overload of planning effort required by the team.
Practicing this type of planning brings not only clarity for the team, but also makes on demand planning easier. Since the team is always looking forward, they have a better understanding of what is coming next. Therefore once the on demand planning is triggered they can go through the bucket lists and plan their next most important thing rather quickly. Whereas a team that does not use the bucket lists, will spend more time doing the on-demand planning, getting to their new direction and next move.
It is completely up to the teams to decide whether they want to use the long-term planning or not, because as mentioned before it may seem unnecessary for some and vital for others. However, in any case it is good for the teams implementing scrumban to be aware of such possibility. In case their needs change they will not be limited to sticking with on demand planning only.
