Document Actions
Prioritizing Your Backlog for Profit
with Luke Hohmann, CEO of Enthiosys
Agile product managers (and their Agile development teams) are told to prioritize backlogs based on ROI. In practice, this isn't possible. Prioritizing for Profit is a better approach. By defining a core set of attributes that include stakeholder preferences, corporate strategy, and specific ways to increase profitability, product managers can create backlogs that support the company's longer-term goals as well as short-term development needs.
Watch "Prioritizing Your Backlog for Profit"
|
|
About the Presenter
Luke is a recognized expert on agile product management of software products and a former senior software product manager at four companies. He is also the author of three books and numerous articles on software product management. He is also a frequent speaker at software and other industry events.
Before founding Enthiosys in 2003, Luke was vice president of business development in the U.S. for Aladdin Knowledge Systems; vice president of engineering and product development at Aurigin Systems Inc.; education technical director at ObjectSpace Inc.; and vice president of systems engineering at EDS Fleet Services.
He loves his job, and is happiest when he’s helping his clients build great products and services. He’s especially enjoys watching clients get excited about creating new products and services as the result of playing Innovation Games® with their customers, integrating these into new product development practices, and creating them through architecturally sustainable Agile methods.
Luke’s counsel is sought far and wide. He is currently a member of the Agile Alliance, having been involved for more than a decade in the Agile community. He has been a featured presenter at numerous conferences including the Software Development Best Practices 2006 and 2007 conferences, The Spring Experience, and The Better Software Conference & Expo. He has also been a guest lecturer at the University of California at Berkeley’s School of Information. He is a member of the Product Development and Management Association (PDMA), the Association for Computing Machinery (ACM), and the IEEE.
Luke graduated magna cum laude with a B.S.E. in computer engineering and an M.S.E. in computer science and engineering from the University of Michigan. In addition to data structures and artificial intelligence, he studied cognitive psychology and organizational behavior. He is also a former National Junior Pairs Figure Skating Champion, as well as a certified aerobics instructor. In his spare time, Luke likes roughhousing with his four kids and his wife’s cooking. He also enjoys long runs in the Santa Cruz mountains to burn off his wife’s cooking.
Contact Luke at lhohmann@enthiosys.com.
Multi-Level Cost Estimating
1. The estimated level of effort (LOE) associated with creating the item;
2. The amount of time it will take a given development team to create a work product based on that level of effort.
Agile teams typically create three LOE estimates:
1. “Shirt size” (S, M L, XL, XXL) LOE estimates are provided by one or two trusted members of the engineering team before release planning;
2. Wide-Band Delphi (Points) LOE estimates are created by the development team during release planning;
3. Task based LOE estimates are created by the development during iteration planning.
To gain increasingly accurate LOE estimates, a product manager or project manager can require that pre-defined size limits be imposed. Any item that exceeds the size limit must then be further elaborated into multiple smaller items. Note that LOE estimates cannot be transferred among different teams. Once you have these LOE estimates you can create increasingly accurate cost estimates on a per term basis. For example, if the data from your last releases indicates that it costs you $500/point, and your team estimates that a given item is 8 points, then it is approximately $4,000 in fully loaded costs. Keep in mind that these costs do not include “end game” and other costs associated with preparing the release.
The Backlog
Three options to help in micro/macro estimating
Prioritizing macro items is easier when you have a solid roadmap, because your roadmap should capture these macro items and how they will be delivered over time. We invite you to attend our webinar on roadmapping to learn how you can do this.
When prioritizing micro level items that work to fulfill macro level items (where you might think of a macro item as a single backlog item in Persona – Problem format from Requirements that Work and a micro item as one specific backlog item that works with other micro items to solve the identified problem), it is helpful to maintain a link from the micro level item to the macro item. This way you can be certain that you have a mix of micro items that all support macro items.
When you have a very large number of small bugs that have to be fixed, we recommend creating a one or more “bug fix” backlog items, assigning them a point value that is large enough to allocate enough work to the development team, and then adding this “bug fix” backlog item to each iteration in your release. You can then defer the specific set of bug fixes to later in the planning process, safe in your knowledge that you’ve allocated time for this activity.
Different Weights for Groups
Pricing Items in Buy a Feature
Yes, we recommend setting different weights for the three broad categories of attributes as well as individual entities that are driving within a group. The goal is to provide transparency and clarity in the decision making process, and to help you get clear about your prioritization choices.
As for managing a large ERP company with 20 products and 7 product managers, I recommend the approach that we developed for our client VeriSign and published at the Agile-07 conference here. Briefly, we recommend that portfolio managers establish a portfolio of major initiatives that are used for allocation of resources among product teams, paying special care to manage initiatives that cross more than one team. Then, each individual product manager creates a roadmap that is then integrated into a roadmap-of-roadmaps that is managed by the portfolio team. You may also want to establish the role of a platform product manager in charge of the platform and put market-facing product managers in charge of market facing deliverables.
Silos can be bad… or good, if they enable teams to work efficiently. Look for the natural areas of overlap. Consider product line architectures and architectural patterns as a way to leverage natural synergies.
We generally recommend that the cost of an item (a product feature in a backlog or a project in a project portfolio) in the Innovation Game® Buy a Feature be related to reasonable estimates of the cost to create the item. You’ll have to determine reasonable based on your circumstances. In a recent project that we completed for a customer, we used “shirt size” estimates to establish high-level costs and then converted these into reasonable numbers. It was the relative costs of the items that mattered during the estimation. We have much more information on Buy a Feature at www.innovationgames.com/the-games/buy-a-feature/.
THe Product Manager
Influencing Architectural Change Through Roadmaps
The intrinsic perspective deals with the internal qualities of your solution. Once again, you should use your roadmap to help you influence architectural changes. By discussing your concerns, ideally supported by market evidence that your product is lacking some aspect of intrinsic quality, you can work with the development team to ensure that any required technical changes are added to the roadmap so that they can be added to the backlog.
We invite you to attend our webinar on roadmapping to learn more about these techniques.
Cost Estimating Techniques