I use the term Bucket Planning for Release Planning. The metaphor works because buckets overflow if overfilled. There are risks associated with Release buckets corresponding to Minimum Viable Products (MVP). A large MVP bucket has gone bad and a MVP Bucket that continues to grow is a Bucket gone really bad.

Large MVP = Bad Bucket

Any large bucket is a bad bucket but a large MVP is particularly bad. The bigger the MVP the longer it takes us to launch and learn from the product in use. Delaying that moment means we continue to rely on our rather academic expectations of user behaviour. It is all in the name “minimum” should be “minimum”, or put another way, for an MVP small is beautiful.

Growing MVP = Really Bad Bucket

A large MVP is a problem. A growing MVP is even worse. Every extra User Story in the MVP means a delay to launching the product. And that delays the learning from having a product live. There might be financial and benefits issues with this delay as well. A longer development costs more. A delayed launch delays any benefits. Bad. Bad. BAD!

What about non-MVP Buckets?

The only buckets that can go bad are those tied to a big launch. This includes the MVP but also major re-launches. These are bad because

• the functionality being built can’t be put in front of real users
• additional cost of development
• delayed benefit of new functionality

In contrast a big release that can be delivered in an incremental iterative manner is not a problem. The release in this case is just a useful handle for a collection of related functionality. It can be large. It can be growing. But neither matters as long as product continues to be delivered in a regular and timely fashion.

Of course the business has to accept that when the money runs out then development stops. So it is in their interest to prioritise the high value functionality first, irrespective of the release it is tied to and how big that particular bucket is.