Inspired by the presentation on coaching and leading Agility to further my product thinking, I decided to learn a lightweight way to set portfolio strategy and priorities. In his presentation, Simplify Project and Portfolio Planning With “Real Options”, Matt Barcomb explained the need for a different mental model for our projects and how we plan them.
Since software development is more like R&D than construction, you should approach your product planning like you plan your investment portfolio. Just like in new product development, your investment portfolio does not have a certain outcome, yet you determine a strategy to meet your goals and allocate your funds. The same approach applies to product/portfolio planning: identify your benefit segments (product lines, lines of business, cost centres), allocate based on capacity and then fill with options. Options include ideas, features, projects, and SMURFs (Specific Marketable Useable Realistic Features) – another way to view minimum viable products.
It is important to understand why before you execute on any option. Creating a Benefits Map will help provide clarity on what options you should pursue and why. Start with creating a mind-map, two to three tiers deep, of the key types of benefits created from doing work on the product. Rank your top 5 benefits, weight them to the nearest 5%, then create a high to low scoring for each benefit. Finally, score each of your options against the top 5 benefits. Barcomb’s example of a completed Benefits Map is below:
After completing a Benefits Map, determine your triggers for starting and stopping work. These triggers are events or conditions that determine or prompt when work on an option starts or whether that work should continue. While triggers may have a time frame associated with them, they are not deadlines. Triggers are based off of real business events or conditions, which continue to apply in the reality of changing situations while the relevance of deadlines may change over time and become arbitrary.
Once the benefits are understood and triggers are determined, then do the classic risk and cost assessment. Learn just enough about the cost to determine whether or not to start work. It is not an assessment based off an exhaustive estimates exercise. For risk, use a simple score of 1 to 3 and multiple it with either cost or benefit.
Options with the highest benefit to cost ratio will bubble to the top of the list and the triggers will determine which ones will start first.
More Articles From Agile Development Conference East
Sockets and Lightbulbs 
November 13, 2014
Agile