New to agile? 3 ways to cut scope (and live)

The primary way I see teams release products faster is by reducing the scope of each product.  However, this can’t be done in an arbitrary fashion.  There are real business reasons for each feature request (hopefully anyway!).  Having seen teams reduce scope successfully I’ve seen three primary ways it can be done.  In order to deliver 50% faster teams can:

1. Deliver 50% fewer features
2. Deliver all features but with 50% fewer bells and whistles per feature
3. Deliver all features with a sliding scale of bells and whistles per feature

Let’s look at each of these separately to see how they work.

Deliver 50% fewer features – This one is obvious and the easiest to make work.  Because agile uses a prioritized backlog of work, a product owner can simply have the team work in priority order until enough value is delivered to make a reasonable release.  A danger here is not being aggressive enough on how much is enough.  Most product owners still go overboard and allow features to be added until the product is well past the point of being releasable.  I believe this is due to product owners being conservative by nature.  Again, this method is simple and effective, except when the sales and marketing teams have “promised” features which are further down the priority list.  If a team delivers 25 of 26 promised features the customer can be upset.  If they deliver the same 25 features when only 20 were promised they are instead praised as heros.  Be very careful with the external commitments so they can be met!

Deliver all features but with 50% fewer bells and whistles per feature – This is a bit different.  It avoids the problems of the method above because all features are being delivered.  This method is relying on studies which show 64% of features are rarely or never used (Standish Group).  In order to deliver 50% faster, 50% of each feature could be eliminated and statistically still not hit the “core” of the software which will be used most of the time.  The drawback here is each feature is treated equally and there is a likelihood too much will actually be cut from some features and not enough from other features.  Which leads to the final method…

Deliver all features with a sliding scale of bells and whistles – In this method the highest priority features are fully developed while the least important features are developed only enough to say they work properly.  The features in between the extremes have a decreasing amount of robustness for each drop in priority.  This allows for the most important features to be the most useful and the least important features to be the least useful.  This overcomes the objections of the first method because all of the features are delivered, while also overcoming the objections of the second method by delivering maximum value for the highest priority items.

I think of the three methods as slicing scope horizontally (a horizontal line through the backlog showing our last feature to be developed), vertically (a vertical line to the right of each backlog item showing how much of it will be developed compared to the maximum) or diagonally (a slanted line to the right of each backlog item showing how much will be developed compared to the maximum).  The first method is clearly the most common, but the problem of leaving off externally promised deliverables is very real.  The last method is much harder to accomplish, but it can be done.

In the last method one way to accomplish it is to create a thin slice of each feature during early iterations.  In this way the product owner knows all the features could be delivered at any point in the future if robustness didn’t count.  From that point forward the product owner can prioritize how much time and effort should be applied to each feature and create the appropriate sliding scale – even properly accounting for changing priorities if necessary.

Too often we fall into the trap of believing every part of every feature needs to be delivered.  When expectations are properly set this is rarely the case.

Until next time I’ll be Making Agile a Reality™ for my clients by helping them cut scope using the method which allows for maximum value to be delivered in the minimum amount of time.