Agile Development Blog

If you have ever wondered what to do with the growing number of features in your software applications, you are not the only one. There is some useful guidance from The Standish Group survey quantifing that only 20% of all delivered software features are “often or always used.” For a team under the pressure of today’s economy to do more with less, here is a way to conceptually cut 80% of your effort and still deliver the high-value essentials. But wait it gets better. If you do not completely elaborate, build, test or document these features, you save once. But you also save again: with the future maintenance costs, the training users, the bug fixing and the regressing these features would have required. This is clearly the biggest lever for cutting software development costs using Agile. And yet it seems to be the hardest to attain.

Features used in Commercial Software - Reported by Jim Johnson of the Standish Group at XP2002

This pairing back to the simple, important few takes tons of discipline and that level of discipline is only be made easier as your agility maturity increases. Most agile books and coaches will call this the discipline of “Brutal Prioritization.” The folks from 37Signals call it: “Getting Real.” In either case, brutal prioritization means two things:

1. Not letting the fat slip into the backlog
2. Keeping the backlog prioritized by value and risk

First, lets talk about fat or wasteful features. Please note, fat or wasteful features come from all directions from the business and customers, but also from developers, support, and product owners. Your features may be fat or wasteful if they:

1. Do not help the most important user persona in your domain achieve breakthrough results or competitive advantage
2. Have not be proven to work and are based on a hopes and prayers
3. Look like pets that someone is protecting
4. Are weak features that degrade the product because they are not complete enough to meet minimum expectations

Photo © Tristan Savatier - http://loupiote.com/ - Used by Permission

So if you are in the customer role or customer proxy role such as the Scrum product owner role, the technical product management or a business analyst role, it is your job to control yourself and help the team to keep the fat off the backlog. If you are on the agile team, it is your job to keep these roles honest about WHY these features are so valuable. This leads right to ranking the items into a prioritized backlog. (A few comments in this area would be really helpful – let’s hear what you use to spot fat features?)

To spot and eliminate fat and waste, you have to focus on value and risk. In prioritizing the backlog, rank items based on the value they bring or the risk they address. Here are some examples of value we use for ranking at Rally:

• A major new or strategic opportunity has committed to buy the software with that feature in it
• Our customer Feature request board has this voted into the top 10
• We have proven it decreases manual errors and we can quantify the savings
• A competitor is beating us with that feature and we can quantify the losses
• It is shown to be the root cause of costly bugs and non-functional bottlenecks (i.e. performance, exceptions, long downtimes/migrations)
• It is broken
• It is proven innovation that has been prototyped and tested
• It opens a new market that is quantified and targeted

To make this prioritizing process easier at scale, product and demand management solutions like Rally’s Product Manager correlate and normalize these value and risk ratings. This aids the product owner prior to and during release planning and kickoff meetings. Once you are disciplined enough to declare, track and show the rankings it is easier to fend off fat and waste. You and your “product council” just have to compare “hot” new requests to business value of existing items in the backlog. (So, what other value indicators do you use that I have missed here?)

We know agile teams cut costs by keeping the fat off of thier software and not writing code. Tell us about your team success in keeping the fat off early and through the development process. Or, comment and tell me about the biggest piece of fat you have ever seen in commercial software.

About the Author: Ryan Martens is an avid outdoorsman, founding board member of the EFCO, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.