As a long-time software developer and development team leader, one of my passions is working with high-performing software development teams. For those in our industry that have worked with a great development team, you understand the difference in productivity can be tremendous. So the goal of helping teams improve their performance has always seemed to be a righteous (though often elusive) goal.
It seems that benchmark for the ultimate high-performing team normally consists of a couple of smart guys in a dorm room, basement or garage. So it’s worth asking what those teams have that the average development team does not.
A tricky question for sure. My experience leads me to believe that the secret lies in the fact that they were both the development team AND the product visionaries. This creates a single source of input (what most of us know as “requirements”) for the development team and creates an enormous source of efficiency. As product managers, product owners and stakeholders, this example gives us a tangible area where we can positively influence the productivity of our software development teams.
Agile software development best practices acknowledge the importance of communication between the business and the technical team. Probably the most significant is the existence of the product owner role. Having been in this role a couple of times, I can tell you that there is no easy day as a product owner. The ideal product owner is one person with the experience, authority, and bandwidth to make all decisions regarding what features go into their product, as well as the priority with which they are added. Development teams that have had the luxury of working with a product owner that meets all these criteria will tell you that this helps their efficiency tremendously.
However, having a single product owner is often impossible or impractical for a variety of reasons. Perhaps the company culture is one where a committee makes decisions. Maybe the product footprint is large enough that one person can’t understand it all. Possibly the product has such a broad range of users and business goals that multiple stakeholders makes sense to represent different user’s interests. In these cases, it is critical to get clear on how the collective group assigns value and priority to a particular feature.
The reason a single product owner is a best practice is because that person only has one way to measure the value of a feature. They have their understanding of what is important, and might occasionally be swayed from that by other stakeholders. But generally speaking, they just decide what to do next and communicate that to the development team.
When multiple stakeholders become active participants in deciding feature priority, things get complicated. This can result in unclear or ambiguous direction to the development team. The reason this occurs is because now you have different perspectives feeding the priority. Something as simple as one person valuing new customer obtainment, while another values maximizing revenue from existing customers can cause major inconsistencies in how importance is conveyed to the development team. Throw in other common themes of software product enhancement such as usability, performance, new market penetration, competitive threats, lowering maintenance costs, integration with new business partners and keeping up with technology platform advances and you have a majorly complex value system that is driving priority.
In order to cut through the complexity inherent in a situation with multiple vocal stakeholders with competing priorities, there is a simple tool I have used to help with prioritization, and ultimately help the development team get what they need to stay efficient and productive. The idea is to score each new feature with a weighted average system to create a numeric priority.
Let’s say the group of stakeholders agrees upon the following three primary business drivers for their new mobile app:
- Attract new users
- Retain existing users
- Lower support costs
Further, the group agrees that they are currently focusing on growing the user base as the primary goal, and that while lowering support costs is important it should be considered the least important of the three. So they could assign relative weights as follows:
- Attract new users – 50%
- Retain existing users – 30%
- Lower support costs – 20%
Creating this definition of how to measure value of a feature is a critical discussion. If you can get the group of stakeholders to agree to this, then you can have this discussion one time instead of having it every time a new feature is being considered. Take as much time as you need in order to drive alignment on this measurement system. It’s important.
Now that the measurement system is in place, as a group you can consider each feature and rate the feature’s value on a scale of 1-5 (1 = least, 5 = most) against each of the criteria. So for a feature such as, “add chat capability to the app,” the group produces this:
- Attract new users – 50% weighting : Group score (1-5) 4
- Retain existing users – 30% weighting : Group score (1-5) 5
- Lower support costs – 20% weighting : Group score (1-5) 1
This allows you to generate a numeric score for this feature. You’ll find that instead of discussing how valuable a feature is as a group (which can be an emotional and complex discussion), you’ll be discussing to what extent a feature can “attract new users” on a scale of 1-5. This is a much easier discussion to have, and compromise comes quickly by using the 1-5 scale.
This exercise can be done with dozens (I’ve even done it with hundreds) of features relatively quickly. Once completed, every feature has a numeric priority that considers the primary business drivers that everybody agrees on. Order the features in descending order and you have a prioritized backlog that was collaboratively created by a team of stakeholders.
The best way to accomplish this is to create an Excel document with the features listed down the left side and the business drivers listed across the top. Then, fill in the matrix for each score and create the formula to compute each feature’s weighted average score.
You can create your own template, or download our feature prioritization matrix to get started:
I have literally watched the anxiety leave stakeholders’ faces when the list is sorted. The stress they felt around having to campaign for the features they thought were most important instantaneously disappears. This can be either because these features were indeed the most important or because they were not the most important when compared to the other features in the backlog. There is great relief in knowing in either case. It’s a simple but powerful tool to get through what can be a politically charged exercise, and it will help your development team’s productivity by providing clear direction.
Tip #1: I’ve found that many people want to include the “cost to implement” of the feature as a business driver. The idea is that if something is inexpensive to build, but has a lot of other values then we should prioritize it highly. I typically advise against including cost, or if you do, weight it very low, for two reasons. First, these features are often high-level ideas at this stage of planning and normally have not been estimated, so cost to implement is very difficult to know. Second, if you assign too high of a weight to cost to implement, it can make it difficult to ever make any significant sized enhancements bubble up to the top of the priority list.
Tip #2: I’ve also found that many people like to include “ability to generate revenue” as a business driver. I also recommend against this. Again, the assumption is that any feature that is being talked about here has already been vetted in terms of ROI. Also, generating revenue is a by-product of most other business drivers, such as, “Attract New Users.” Including revenue generation by itself usually ends up double counting the revenue benefit that already exists in other categories.
Talk to us about how our agile project methodology can speed the development of your next digital solution.