In the Agile Product space, there are a few key people who are leading the way.
Jeff Patton – leads the way from an innovation and creativity perspective. Jeff’s storymapping technique is being used nearly everywhere to gain additional perspectives of backlogs beyond a simple list of requirements.
Ellen Gottesdiener – leads the way from a traditional requirements mapping perspective. Ellen has a strong Business Analysis background. As agile matured, she joined that approach and has added much in the way of mapping traditional analysis to agile analysis.
David Hussman – has partnered with Jeff Patton on many an occasion in his storymapping workshops. David has the uncanny ability to “see beyond” our current approaches and to keep us grounded in “what matters”, while reminding us to ever challenge our staid approaches.
Roman Pichler – leads the way from a Product Ownership perspective. He focuses on valuation, forecasting, and roadmapping. I’ve always felt that my product ownership book focuses more towards the tactical role and Roman’s on the strategic. It doesn’t hurt that he’s a prolific contributor to that space.
And finally, Marty Cohen – leads the way helping us understand the nuance of Product Management as it related to agile products and Scrum Product Ownership. This is often an underexplored area in agile and Marty brings deep experience in Product Management, with an “agile slant”.
Why the Who’s Who?
I don’t know. I guess I felt inspired to share the love a bit with some of my colleagues.
It also serves as a nice segue into the topic of this article. Ellen Gottesdiener wrote an article a while back entitled – Value: The Lynchpin in Agile Product Management. She posted it on her blog and on LinkedIn. I read it on LinkedIn. In the article, she recounted the feedback she received in a product working group session. The insights shared were “right on” and I thought insightful.
So I want to thank Ellen for sharing it.
However, I did want to play off of the article and add some additional perspective.
Determining value without cost accuracy is dangerous.
In the article, the group came up with the following tools for determining value:
- Cost of delay
- Economic value added
- Net present value
- Net promoter score
- Prioritization matrices
- Value considerations
- Value points
All of which strikes me as independent valuation tools. I don’t see the complimentary cost side amplified where I would like. And not just a guestimate as to cost, but something that also explores the variance (risk) associated with cost.
I guess the point I’m trying to make is that you can’t determine value unless you have a firm handle on the cost (capacity, velocity, points associated with, cost per point) of your team. And it’s not a hand-wavy sort of velocity that I see all of the time in my coaching.
I’m talking about teams that have achieved a predictability or a certainty to their velocity that can be counted on for valuation AND planning.
And that leads into my other point. Cost needs to also consider the impact to plans. For instance,
- IF we take on this additional work;
- What is the size of it?
- And what is the risk associated with the estimates (variance)?
- And IF something goes awry, what would be displaced in the current forecast in order to deliver this work?
- And, would the loss of that be offset by the value of this new work?
So I want some capacity-based risk analysis as part of the valuation effort. An extension of this needs to also consider quality or consistency of achieving your definition of done.
Another way of saying it is – what is the typical degree of rework that your work (features) require. I want that effort to also be included in the original valuation AND in any decision-making when re-valuating work relative to other work.
The group also had another interesting observation.
Value is in the eye of the beholder
Ellen made one key point that value is certainly not a fixed metric. Rather it’s a variable metric that is in the eye of each receiver (customer). Something that has a perceived value to one client, may have little to no value to another client. Here’s a snippet on this topic:
When we asked ourselves, “whose value do we care about?” that bright day in Boston, our conversation got deeper. We dove into who are our product partners—what some call stakeholders. These various partners have diverse views about what they think our product’s value is. The best products evolve from collaboration among all the product partners, led by a smart and passionate product person.
Product partners come from these realms: Customer (users, choosers, advisors); Business (sponsors, product champions, business partners, subject matter experts); and Technology (product makers who define, analyze, design, architect, develop, test, document, and support the product).
It’s the aggregated value that’s important. Not only from your partners, as Ellen suggests, but from your users and customers as well. One of the trends nowadays is to measure usage data as a way to verify your core priority and ROI (value) assumptions as part of your application development.
Part of this encourages the use of prototyping and experimentation in “testing” your value assumptions. So investing a little to gain a lot of insight and confirmation. That’s an incredibly healthy (lean and agile) approach and I’m not sure it was amplified enough.
Wrapping up
Ellen’s readout made me think about value beyond the normal (valuation and rank ordering) process that is so typical of agile teams.
Even in the SAFe model and it’s “more formal” WSJF (weighted shortest job first) prioritization / valuation approach, they don’t really consider cost accuracy the way I would like. Nor quality / rework variance.
I guess I’m coming back to the earlier point – value is in the eye of the beholder. And I would prefer that value consist of a solid component of honest cost and rework variance. And under rework, I would include – external interruptions, priority changes, and business shifts.
You see, while agile is change friendly, change is not cost free. Let’s start focusing on that as well when we’re managing value/priority in our work backlogs.
Stay agile my friends,
Bob.