Scaling Agile, Step 2: Traditional Portfolio Scoring
Scaling Agile is the key to successfully adopting Agile.
We previously covered how to scale Agile using Kanban feature flows. In this post, we'll cover scaling Agile with traditional portfolio scoring on features.
Your Kanban board (from step one) includes a portfolio of features that the stakeholders think are a good idea to add to your product. These are features for which you’ve done a business case and balanced the benefits against the expected costs. So, you've ultimately determined that each feature will add value to the business in some way.
Someone in authority (likely the product manager or a board of executives) has approved the features and moved them into the product backlog.
Now you’re ready to begin work, but which approved feature is the most important to work on first?
You can do this by:
- Using weighted scoring.
- Building an Agile prioritization matrix.
- Automating your scoring system.
Using Weighted Scoring
To be certain, you need to establish a priority for all of the features in the portfolio. And to do that, you need a scoring system.
A weighted scoring system is a very common project management technique. This sort of approach will be very familiar to all you PMs out there, as well as anyone who has studied Prince or PMBOK. It will also be familiar to anyone who has been involved in traditional Project Management Offices or steering groups.
For those of you who may not be familiar with scoring, I’ll explain it here and describe how it works in agile lifecycle management tools. The great thing about using these tools for portfolio scoring is that it does all the calculation for you directly within the repository. So, there’s no need to transfer the information to a separate Excel spreadsheet. It eliminates all the effort and risk that duplicate data stores entail.
How Weighted Scoring Works
Let’s say you have three features in your portfolio.
The first feature came from the CEO, who mentioned that you should “think about” adding it. Certainly, the CEO’s opinion carries some weight, and may bias you toward working on that feature first.
But the second feature is something you’ve wanted to implement for some time, and it will greatly improve the product. So, maybe you should work on the second feature first.
Then there’s the third feature. Your competitors already have it in their products. And Sales is convinced users will jump ship if you don’t include the feature in this release.
In a perfect world, you'd have the resources to work on all three.
As it is, however, you can only work on one at a time. And there’s a good chance whichever feature you pick will be the only one you can complete by the release date.
So, which should it be?
A weighted scoring system is a good way of obtaining an objective point of view when you have to make this kind of decision.
Scoring helps you evaluate each feature request without bias. You’ve probably used a weighted scoring system in your personal life without even realizing it. Complex purchases like buying a car or choosing a new computer force you to weigh the features of several models and decide which features are “must have,” which are “nice to have,” and which features you don’t need at all.
For example, if you’re buying a new computer to play video games on, you’re going to give more weight to features like processor speed, the graphics card, and so on — knowing you’ll pay more to get a machine that meets your needs.
However, if you’re buying a computer for your dad, who is only interested in surfing the web and getting his email, you may give more weight to features like built-in Wi-Fi, ease of use, and a low price.
You may not make a written list of features and assign them scores, but you’re still using a weighted scoring system.
In a product development context, scoring is more structured.
Features are scored on a range of criteria unique to your product and company (for example, feasibility, expense, effort, and so on). The weights assigned to each criterion are subjective, but must add up to 100 percent. Then, each feature is scored on a 1 to 100 scale for each of the criteria, and that score is multiplied by the weight percentage. Each feature's score is then added up to give you the overall priority score for that feature.
Building an Agile Prioritization Matrix
Once you have assigned all the scores, what you end up with is an Agile prioritization matrix.
Using our three-feature example from earlier, the prioritization matrix may look something like this: According to these scores, the third feature (the one Sales is pushing for) should be given the highest priority.
Obviously, this is a simplified example. In the real world, you’d likely have many more features to score, as well as more criteria. And that’s when doing weighted scoring manually can get confusing and time-consuming.
Automating Your Scoring System
Fortunately, you can use tools such as Helix ALM to automate your scoring system, whether you use weighted scoring or a different scoring system.
You can score your features in the way you prefer — even if it’s a custom scoring system your team creates itself. And you can use calculated fields to configure custom fields that automatically calculate numeric, text, date/time, pop-up item, and time span values based on other field values.
That means you can set up an Agile prioritization matrix using whatever scoring calculations you prefer, and you’ll get something like this — which is simply a filtered list showing all the items in your the feature backlog:When a new feature is added to the backlog, it automatically gets added to your Agile prioritization matrix for scoring, using the predefined calculations.
This takes the tedious manual effort out of traditional portfolio scoring and makes it much simpler to determine the priority of each feature request.
Prioritizing your features manually or in an automated tool, with weighted scoring or some other method, helps you approach your work objectively.
At the end of the day, portfolio scoring is a valuable tool to guide your decision-making. It can mean the difference between choosing a feature with actual value, rather than perceived value — ensuring that your team is working on the most valuable feature in the portfolio first.
Scaling Agile, Step 3: The Roadmap Document
The next step in scaling Agile is the roadmap document, which is how you plan when you’ll deliver the features in your backlog.