January 20, 2016

Scaled Agile, Step 2: Traditional Portfolio Scoring

Helix ALM
step2In my last blog post, I talked about the Kanban feature flow, the first step in scaling Agile. In this post, I’m going to dive into Step 2, traditional portfolio scoring. Step 1 should have left you with 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, ultimately determining 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? 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, so this sort of approach will be very familiar to all you PMs out there, as well as anyone who has studied Prince, PMBOK, or 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 TestTrack. The great thing about using TestTrack 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.

Using Weighted Scoring

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 it 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? chart_small_transA 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. This six-minute video shows how this process works in greater detail: https://youtu.be/FefJ1paq750

Building a Prioritization Matrix

Once you have assigned all the scores, what you end up with is a prioritization matrix. Using my three-feature example from earlier, the prioritization matrix may look something like this: weighted scoring 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 TestTrack to automate your scoring system, whether you use weighted scoring or a different scoring system. Because TestTrack is insanely flexible, you can score your features in the way you prefer—even if it’s a custom scoring system your team creates itself. TestTrack's calculated fields allow you 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 a priority 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: [caption id="attachment_18148" align="aligncenter" width="900"]s2f1scaled agile (Click to enlarge.)[/caption] When a new feature is added to the backlog, it automatically gets added to your priority 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 a tool like TestTrack, 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.

Down the Road to Step 3

The next step in scaling Agile is the Roadmap Document, which is how you plan when you’ll deliver the features in your backlog. I’ll discuss the Roadmap Document in greater detail in my next blog post. Again, you can watch my recorded webinar, Six Steps for Scaling Agile, if you want an overview of the entire process. If you have any questions, please leave them in the comments.