Identifying Low Hanging Fruit
The secret to creating software quickly
Making software takes time. Making good software takes even longer. Yet, if you ever worked in a software development team, you’ve most likely come across one of the biggest anti-patterns of the industry: scope creep, requirements changing while the software is being coded.
This is something unimaginable in other fields where the final product is more concrete than some pretty pixels on a screen. Imagine a cook who’s asked to make an apple pie and, while the pie is already baking, being told to change that to a lemon meringue cake. Short of throwing themselves (or the customer) in the oven, there isn’t much choice for our poor chef than to dump the pie in the bin and start all over again.
Not in software. We need to adapt and accommodate during implementation, and sometimes compromise quality to get something out of the door before the expiration of a deadline often decided with little to no input from the guys doing the work itself.
Well, today we’re going to look at a technique which should allow us to release functional software more quickly. This technique isn’t meant to replace a full SDLC process, but you’ll see how easy it is to slide into your own process and immediately gain velocity.
Let’s start with the basics first.
The Pareto Principle
The method we’re going to look at relies on a principle observed by economist Vilfredo Pareto back in the late 1800s: that roughly 80% of the effects come from 20% of the causes.
For instance, roughly 80% of sales come from 20% of the customers and, closer to home, 80% of errors can be fixed by addressing the top 20% of bugs reported (at least according to Microsoft’s then-CEO Steve Ballmer in the early 2000s, based on stats collected over Windows XP and Office).
Some people, such as Allan Dib in his “The 1-Page Marketing Plan” book, even go as far as applying the rule onto itself and claim that 4% of the effort produces 64% of the results (for the maths behind it: 20% of 20% = 4%, 80% of 80% = 64%).
Now, I’d take the latter, and in general all the absolute numbers around these principles, with a pinch of salt, but past observation on projects I worked on seem to support this broad principle: it takes comparatively much less time to get to 80% of our target than to complete the last 20%.
In other words, if we can identify the biggest winners in our requirements list, we can quickly get to satisfying the customer’s ultimate needs with much less effort than if we were to mindlessly go through the whole list.
Let’s see if we can identify these winners.
The low hanging fruit
What is a low hanging fruit? In our context, it’s a feature that satisfies two basic requirements:
- It’s in high demand
- It’s easy to do
High demand is something that should be determined by our customer (or their proxy, i.e. the product owner in most cases), while easy to do is a consideration stemming from engineering, produced by taking into account the most important elements of implementing change, such as complexity of implementation, impact on the codebase and maintainability.
Working on the low hanging fruits and releasing them early can help us take the pressure off the team and allow for the right amount of time to be invested into still important but more complex tasks.
In other words, working solely on low hanging fruits doesn’t take us to completion, but working on them early can take us closer to the end goal much more quickly.
Now that we know what a low hanging fruit is, let’s look at how to identify them.
Determining demand: MoSCoW analysis
The MoSCoW analysis is a simple framework to classify requirements into different buckets according to their impact and significance to the customer.
Doing a MoSCoW analysis means taking each feature / requirement and put it into one of the following buckets:
- Must : Something that must be done. Without it, it doesn’t make sense to release the product.
- Should : Something that should be done. We can probably live without this feature, but we risk losing a significant amount of customer interest if it’s missing.
- Could : Something that could be done. It’s a “nice to have” that makes the product better for our users, but at the same time it isn’t all that critical for our success.
- Would : Something that would be nice to have. If you’re done early, this is a nice “cherry on top”, but really it’s neither required or impactful to the majority of our customers.
Looking at these buckets, you might be inclined to think that such classification is something product management (or the product owner) could do on their own.
This is often the case, and it’s a shame since it’s missing a key factor that can have a huge impact on the final sorting: time to market.
I can’t overstate this enough, so let me give it the emphasis it deserves:
MoSCoW is useless if time to market isn’t taken into account
The market (and our competitors) aren’t going to wait for months for our Musts to be completed. They’re going to move on. That’s why it’s important to do the MoSCoW analysis jointly between product management and engineering. If we were to identify a Must which isn’t feasible in a reasonable time frame, we need to find alternatives, the sooner the better.
At this stage, we are at a good place to start identifying some low hanging fruits, namely those Musts with a short implementation time. However, the picture is incomplete without taking difficulty into account.
Determining difficulty
If your team is already using an agile-like development methodology, you’re probably familiar with the process of assigning points to each story that enters the backlog. However, often points mean different things to different people, and this is why I didn’t want to just say: low hanging fruits are 0pt and 1pt stories from the Must bucket.
In order to determine a real low hanging fruit, aside from the implementation time considerations we already looked at just now, we must consider the difficulty of each story and indeed pick the least difficult ones from the Must bucket.
Again, we could use a point system to determine difficulty, but to avoid confusion between this and implementation time, let’s use a simple scale instead: let’s classify our stories as low, medium and high difficulty.
The biggest factors in determining this difficulty rating are risk and complexity. Let’s see how they can help us determine low hanging fruits:
- Risk : Good low hanging fruits are stories where you won’t break much by implementing them, either because they’re completely new, or otherwise because they don’t have much impact on the rest of the codebase.
- Complexity : The more straightforward the business logic being implemented, the less likely you’re to introduce bugs. Low complexity however doesn’t mean low ROI (return of investment). Sometimes there are stories which are of great benefit to the customer, but aren’t really that complex to do. These are optimal candidates for our selection.
A third factor to be considered is specialization, otherwise known as “who in the team can tackle this task?” Specialization can affect timing and scheduling as more specialized tasks might contend on the same engineers being available to work on them, and therefore should be taken into account when selecting our low hanging fruits.
Also, akin to how MoSCoW is primarily a product management-driven activity with some engineering input, determining difficulty should be a primarily engineering-driven effort, but should involve product management as well.
Specifically, the big question for the product people here is:
How finalized is this story?
A good product manager / owner will have a sense of which stories are more likely to be set in stone, and which ones require smoothing and / or further polishing over time. In fact, some might even be experiments which are expected to be A/B tested with users to verify a specific assumption.
That’s OK, as long as everybody is on the same page, and it’s exactly why communication and collaboration is as important here as it is during MoSCoW analysis.
Wrapping up
In conclusion, story prioritization is an important scheduling factor that can determine product success. The Pareto principle tells us that we can achieve 80% of results with 20% of the effort, so we should look at prioritizing this crucial 20% as the first work that we do in a project.
To help us determine that, and therefore prioritize stories accordingly, there are three main factors to take into account:
- The customer need for a given story
- The time it takes to implement it
- How difficult it is to do it
The first step in story prioritization is to use a method like the MoSCoW analysis, being mindful about implementation time as we classify each requirement as a Must, Should, Could or Would. Once that’s done, we can supplement the resulting classification with information on the difficulty of implementing each story.
This allows us to identify potential low hanging fruits: stories which are a Must for customers, and aren’t determined Low Difficulty by the implementation team. If we focus on these stories in the early iterations of a project, we’re more likely to satisfy the customer’s need and buy us time to work out the more complex stories which we’d still need to do to really complete the project.
Even if we don’t identify any low hanging fruit, or if those tasks identified don’t take us all the way to 80% completion of our project, the resulting prioritization of activities can be used as a map to take us there.
Most importantly, these activities give product management and engineering a chance to work more closely together, which leads to a better understanding of the project and its complexity from both parties. Who knows, maybe that’s the real lesson here: using this method, doubts and assumptions can be challenged early on, reducing the risk of surprises when it’s too late and the apple pie is already out of the oven.
That’s a wrap for today. In closing, here’s a provoking thought: do we really need to satisfy all the requirements for a project in order to tick off its definition of done? Or is 80% good enough? If the latter is true, how much more can we do by just focusing on the 20% that really matters?
