I sometimes call a Release Plan a Bucket Plan and the process Bucket Planning. I like the metaphor because if you overfill a bucket you end up with a mess on the floor – and the business gets that.

Release Planning with Buckets

When running Agile projects or programmes for external customers I find it essential to have a Release Plan that covers the entire scope including multiple public Releases. Scope is often tied to contractual obligations and I need one place, the Release Plan, to define the entire scope. I also retain out-of-scope items on the Release Plan, tagged obviously as out-of-scope. Once again this is particularly important in a customer-supplier situation where scope discussions are common.

I call the process of putting together the Release Plan “Bucket Planning”. Business folk understand the metaphor of a bucket and the need to avoid overfilling one.

Bucket Planning is a key part of Agile Project Planning. It assumes each User Story has an estimate. The capacity of a bucket is the expected team productivity for that time period, whether velocity or throughput.

The Product Owner prioritises the User Stories with the higher priority items going into earlier buckets, lower priority items going into later buckets, and very low priority items being declared out-of-scope, i.e. not going into a bucket. The capacity limits how many User Stories, of what size, can fit in each bucket.

The buckets within a Release Plan can be Sprints or the releases themselves.

Bucket Planning with Sprints

Each Sprint (or Iteration or Timebox) in XP, Scrum and DSDM is a bucket. The team capacity is the same for every bucket and limits how many User Stories can fit and the Product Owner cannot overfill any of the buckets. You can put User Stories into any of the buckets but if a bucket is full, you can’t put anything more in it. You have to move the overflow to another bucket or discard it. In traditional project management this process, of making sure that the team capacity is sufficient to do the work assigned to each time period, is called Levelling.

Actually it isn’t correct to say that all of the buckets are the same size. The bucket on the right, out-of-scope, can be as big as you like. Bigger the better from my perspective. As I explained above I keep it, and the User Stories it contains, on the Release Plan so it is explicit what is in/out of scope.

The same principle of Bucket planning applies if using the continuous flow of Kanban except the buckets will correspond directly to a period of time, e.g. a week or month.

The maths of bucket planning for Sprints is very straight forward. If you have five people delivering, on average, two User Stories each within the Sprint then your Velocity for the team is 10 User Stories. If you’ve only got four Sprints then you’ll get at most 40 User Stories delivered.

Bucket Planning for Releases

It is possible to step up a level and do bucket planning for releases. At this level the buckets can vary in size but generally smaller is better. The first bucket, that on the left, corresponds to the first launch – the minimum viable product (MVP).

I’ll addresses the inherent risk in buckets that can grow in a separate post.

Caveat

I don’t rush to do a Release plan but I’ve found I eventually find myself doing one in every gig I’ve had. The customer asks. I do. That might just be the context in which I work. Delivering software for a paying customer.

So worth mentioning that not everybody needs a Release plan. Not everybody has to estimate. Not everybody needs a bucket.