We have been developing software for decades and we have witnessed more software projects fail than succeed. And, most software projects are considered as failed, either because a project does not meet a customer requirement or an agreed project timeline gets missed. We always run into a problem of too many features being promised to be delivered in an impossibly short period of time. We work with a customer, gather requirements and tend to think that we know what a customer wants and make a plan, project the release date and start development. Once we start developing we need more clarification and once we start working on clarification with the customer, as a result, we get more requirements. The customer assumes that additional requirements were part of what they communicated initially so they want all the features to be delivered in the originally agreed upon time. This makes no sense since scope is increased but timeline is not. However, the question is “Are all the requirements must-have for the release?”. As per the Standish group’s analysis, 20% of the software covers 80% of features used in a software product. The remaining 16% are used sometimes, 19% rarely used and 45% are never used. So here is the hidden treasure we need to dig into, how to identify that 20% useful features or how to weed out the 45% unused features so that we provide what customers need in the agreed upon schedule or even early. I truly believe the Agile framework has many good reasons to be utilized, however one that bubbles to the top is that it helps us find that 20% of treasure that provides 80% functionality.
Let’s look at how we can follow Agile principles to identify 20% of the valuable features and save more than 50% of the effort; this means 2x the productivity or even more which is in line with Jeff Sutherland’s (co-founder of SCRUM) book “Twice the work with half the people”.
Agile Principle: “Simplicity–the art of maximizing the amount of work not done–is essential.”
As Steve Jobs said “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are.” Really we add 100s of features and ideas (either requested by customers or added by internal customers) to make a product cool! But it is not about making a cool product; it is about providing the right value to our customers. In many cases, we tend to add more and more features making the product more complex. In other words, rather than making the product better it goes the other way around. So we really need to understand how to weed out the features that do not provide value or provide only low value.
The Product Owner Role is vital in the Agile framework(Scrum). The product owner is on the hot seat to prioritize the requirements based on the customers’ need, market competitiveness, company directions etc. The product owner should work with customers to understand the business need and why they need it and be able to articulate the business value. Just a simple few questions like asking customers why they need it – do they really need it, what happens if the requested feature is not provided, or what happens if the requested feature is delayed by 6 months etc. will weed out a lot of not needed features. This is the reason “Why” or the “So that” statement in the user story format is very strong and provides critical information that generally people underestimate. It really gives the purpose of the feature and gives way to prioritization plus getting you to think about the right solution. If the customer cannot explain why then probably that feature is not of high value or the customer may find it has already been included in an existing feature.
The product owner should prioritize the requirement along with customer and the priority should be forced ranked, meaning rank from 1 to n. The requirement can be prioritized either based on value, the cost of delay or Weighted Shortest Job First (WSJF) etc. The value of software product is based on the benefit to their customers, such as an increase in productivity, an increase in revenue, an increase in customer/employee satisfaction etc. And the cost of delay is how much value the customer is going to lose if the feature delivery is delayed by x time period. WSJF is a well adopted method by Dean Leffingwell in the SAFe framework and is calculated with cost of delay and size of the work(for more detail visit www.scaledagileframework.com/wsjf)
In many cases calculating an exact dollar amount for value and cost of delay takes a high amount of effort and in some cases it may not be possible at all. In those cases, I would suggest estimating relative value, as human beings are more adapted to size relative value better than an absolute value. And using the planning poker game similar to what we used in estimating user story size is the best way to bring more accuracy on value estimation. Similar to developers’ involvement in user story sizing, involve stakeholders (mostly customer facing individuals, at least more than 3 individuals) in estimating user story value and have them use Fibonacci numbers and vote the value. Please refer to the link below for Planning Poker technique for user story size estimation, please apply the same technique for estimation user story
value https://www.mountaingoatsoftware.com/agile/planning-poker. The point of planning poker is getting input from multiple stakeholders in an unbiased manner and stimulating discussion if someone has a different opinion which will further clarify the requirement and its value. This is a very good technique to align stakeholders as per scope and value of the requirement as well.
Once all the user stories are sorted by value then all the low-value user stories go towards the bottom of the list, where you can again question stakeholders/customers if those low-value features are really required and make an effort to take them off the list.
So the bottom line is, be critical in determining the value of user story and prioritize accordingly so that we can negotiate with customers to weed out low-value features and focus on top 20% valuable feature.
Agile Principle: “Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.”
With an Agile mindset we need to strive for delivering the product as early as possible so that we can start getting feedback sooner from end users. I know we do a lot of focus groups, user feedback sessions and these are all good. However, unless the user gets their hands dirty on real product and starts using it, they will not be able to give true valuable feedback. So instead of wasting time to do a lot of feedback on prototype etc. we need to focus on how to deliver Minimum Viable Product(MVP) or Minimal Marketable Feature(MMF) and start getting feedback. We should embrace the fail fast culture, as we know the first version of our product might potentially fail. And failing is taken positively if we can learn from it so that we can recover fast, hence fail fast culture. MVP is the scope of the product that customer can start using and gaining value from the product instead of waiting for all features to be completed. It’s hard to determine the set of features that make up MVP. Usually, customers want all the features they requested to be done before they can really start using it. However, in reality that is not true, subsets of a feature they requested can start giving them value; we just need to educate customers to think that way. And if you start breaking down those features and ask the right questions, you can find gold mines. For example, if the customer has identified 10 features, the first step is to prioritize them with the customer in forced rank 1-n form. And ask all the ‘Why’ questions about all the features, especially the ones towards the bottom of the list. The next step is to break down all the 10 features into sub-features and seeif then if they need all those sub-features one by one. I am pretty confident this way you can cut down 30-50% of sub-features for the MVP release and delay non-MVP features to after the MVP release. Especially in an agile mindset, we want to deliver continuously, along with an early release. Hence, the customer will be more willing to compromise on the MVP since the next release will be 2 to 4 weeks after the MVP release instead of 6 months or so. So many times I hear people in my training saying customers want everything in one release. I really challenge them to go with the agile mindset, have them prioritize all the features and challenge the customer why they cannot start getting value from the subset of the features. This MVP gives early value to customers and at the same time helps us identify those 20% of the features that provide 80% of value. First of all, we become very critical on only providing absolutely needed features in the MVP and after that in every subsequent release as well we work with the customer to critically prioritize the remaining features and in this way we keep on moving low value added feature towards the bottom of the list. Ultimately we reach the point where customers will suggest themselves that low-value features are really not needed.
I hope I was able to shed some light on this topic, so prioritizing the requirements, keeping simplicity in mind and getting feedback early on MVP release and continuously thereafter is the key to identifying the 20% treasure we talked about, thereby reducing the time to market substantially and saving resources making Agile implementation well worth it.
Hope to talk to you again in my next blog :).