Avoiding a Leaky Scope Bucket

There’s a hole in the bucket, dear Liza, dear Liza,
There’s a hole in the bucket, dear Liza, a hole.
– children’s song, Bergliederbüchlein (c 1700)

In my prior article, I introduced the concept of a scope bucket to explain the concept of project scope to your stakeholders.  In this article, I continue the theme with some tips for managing and delivering the scope in your project scope bucket.

Let’s start with a common issue with buckets: leaks.  Unlike a traditional bucket, the problem with a scope bucket is that scope never leaks out, it only leaks in. Project scope creep, as it is commonly called, is responsible for countless failed projects.  Often times, it goes undetected until failure has occurred, and at that point it is too late.

This is a proposed method for stopping the leaks – and the creeps! – which greatly increases the likelihood of finishing on time and on budget.  The first step is to ensure the bucket contains the right mix of requirement priorities.

Filling the Bucket

Prioritize your requirements using the MoSCoW convention:

  • Must: Critical requirements. By prioritizing a requirement as “must,” you are saying that it is not even worth launching the project if these can’t be delivered.
  • Should: Also very critical and should be delivered, but if something really horrible were to happen and these can’t all be delivered, the project is still worth completing.
  • Could: Very important, but more “nice to have” than mission critical.
  • Won‘t: Not going to do these!  So why bother including them?  This is for requirements that were brought up, but it was decided that they wouldn’t be part of the project.  They are included, but labeled as Won’t, so they don’t get brought up again and again and again and…

The healthiest mix in a scope bucket looks like this, where the percentage represents estimated time to deliver and not simply the number of requirements:


Delivering the Bucket

The scope bucket defines scope for your project, phase, sprint, iteration, increment, or whatever you like to call your efforts to deliver some unit of value.

When making a timeline and budget commitment, estimate what it will take to deliver your project based on delivering all the Musts + Shoulds, and not the Coulds.  Estimating like this using the MoSCoW categories provides a powerful way to deliver efficiently and on time.  Here’s how:

  1. Focus on delivering the Musts first.  Of course, scope is rarely that simple and many forces will conspire against this – resourcing and requirement dependancies being some common culprits. That’s why these are guidelines and not rules!  Do your best.
  2. In the unlikely occurrence of unforeseen challenges (that’s a joke), remove the Coulds along with enough Shoulds from bucket to allow you to complete on time.  The Shoulds provide a 30% buffer to face challenges and still deliver sufficient value on time.
  3. If things unfold better than planned and you complete the Musts and Shoulds ahead of schedule, then you can dig into the Coulds and delivery more value than expected!
  4. If new requirements emerge as priorities mid-stream, mathematically negotiate with your stakeholders to remove an equivalent amount of scope from the bucket before adding more.
  5. Do not over-scope the bucket!  Increasing the ratio of Musts in a bucket simply increases the likelihood of failure.  If you must add more Musts (see what I did there?), then you need to increase the size of the bucket.  This means adding cost, time, and/or people to the delivery.

As always, the devil is in the details, but we are strong advocates for having the right framework for working through the details. We have found the bucket analogy and MoSCoW approach provide a very powerful framework for communicating with requirement stakeholders and for successful value delivery.

We have lots more to say about requirements, so check out some of our other requirement articles or contact us about our business analysis capability building.

The following two tabs change content below.

Dan Hughes

Was a principal consultant at Systems Flow, Inc.

Latest posts by Dan Hughes (see all)


Comments are closed.