There was a wonderful commercial I remember from years ago where a matronly woman named Clara Peller judged hamburgers by the amount of beef she found in them. Quite often, when she was disappointed in her quest, she would shout “Where’s the Beef?” in frustration. Wendy’s was the chain who came up with the advertising idea and to this day the line has become a catch-phrase for value delivery and customer expectations.

I guess Clara was onto something though. In my experience, business’ often miss the beef when they’re trying to deliver value to their customers—particularly in the software product arena. I don’t know why that is exactly. Sometimes I think the developers are too abstracted from their customers. They can rarely touch or observe them. Or understand their true challenges. So they’re guessing when it comes to needs—sort of throwing the software “over the wall” for feedback.

Quite often they are under the gun to deliver a smorgasbord of features. Almost as if no one knows what the customer needs, so they shotgun scatter individual features hoping to ultimately hit the customer’s needs. Fingers crossed. While this may be somewhat successful, it also results in delivering low value features that dilute the focus of the team and increase product development costs. From my perspective,  nothing could be more wasteful.

Wouldn’t it be wonderful if we could focus entirely on “The Beef” in application development? Spending most of our energy focused on delivering high-value and high-need solutions to our customers. Cutting through the clutter of disappointment and ambiguity and simply working on what matters most?

While it sounds like a fairy tale, the agile methods aspire to just this purpose. But it’s not easy to achieve and the effective Agile Project Manager plays a wonderful role in this quest. In this post, I want to share some ideas on how to focus the team towards just such value delivery. Fingers crossed…

A Prioritized Backlog!

One of the first mechanisms that drive value is the Product Backlog—the simple prioritized list that drives what agile teams build. Every team should be laser focused on prioritizing their backlogs in 1..n order. There can’t be three or four priority one features—there can be only one; then two, three, and so on.

Trust me; your customers and stakeholders will want to play infinite games with priority. I’ve seen cases where they have groupings in a spreadsheet that are prioritized and then sub-features broken out within each of them. They’ll insist that they can’t decompose the value out any further as they try to overload priority. This (1a, 1b,..1z) approach allows them to escape true prioritization and selection, also indicating their innate inability to make hard choices regarding what’s truly most important. Don’t let them do that!

An effective product backlog is always in linear and priority order. The team will always deliver the highest priority features first. They will work on them first, finish them first, ensuring the customer is engaged as appropriate in their development. They’ll also acquire customer sign-off for acceptance of each story before they move onto others.

And since the customer is the final arbiter of priority, they shouldn’t really complain about this approach. It’s just that we’ve historically allowed them to give us large lists of features without making finely grained priority distinctions—so they’ve gotten a bit lazy.

When encouraged (forced) to prioritize, I’ve never seen a stakeholder who couldn’t do it.

Customer-Driven Value

Prioritization can also be driven by perceived value—change that to should be driven. One technique used by many agile teams is the notion of Value Poker. It’s a variation of the popular Planning Poker technique that is used for User Story size estimation. But instead of determining size of stories in story points, we use value points as the determinant.

In this case you use a deck of cards labeled from 1-10, one being the lowest value and ten the highest. For each user story or theme/collection of stories you ask a group of various customers and stakeholders to ‘vote’ on their view to value of the story. You take a round-robin approach discussing the ‘why’ behind the highest and lowest values—letting the team express their views towards value nuance.

Once the discussion is over, you re-vote and re-discuss until you narrow the value as much as possible. Sometimes you gain agreement across the team. Sometimes you simply get a range.

You might even compartmentalize values from the different perspectives of the team. For example, the quality and testing folks’ might value a particular story as a five, while the business folks’ value it as a three and development or technology folks’ as a one. All of their valuations provide important data as to how you cross-functionally value the feature.  And clearly this spread would generate some meaningful discussion across team members.

This logic might be applied to multiple stakeholders as well. For example, the North American stakeholders might value a feature at six, while the EMEA stakeholders think it only a three. In all of these cases, discussing VALUE as a distinct attribute helps the team in prioritizing and in deciding how much fit & finish to apply to individual features.

A Variation

A truly effective variation on the Value Poker technique is to give every voting or contributing partner a ‘pool’ of funding to spend as part of their voting. So not only are they voting on a value, but they have to invest a portion of a fixed pool of dollars on the feature as well.

Quite often monopoly money or a similarly fun equivalent is used for this purpose.  Let’s say everyone gets $5,000 to spend on their features as we play priority poker. In one particular case, a business stakeholder votes a nine for a feature.

In order to emphasize the importance, they put up $1,500 on the feature or about 30% of their available funds. In fact, they only spend their pool against a total of seven features. While they continue to prioritize subsequent features, they’ve clearly communicated their views towards value. In fact, that $1,500 feature ends up being the #1 priority with a total value pool of $12,000 across the entire voting team OR 25% of the total available pool.

So here’s an interesting question. If you’re implementing this feature, what does #1 Priority convey vs. #1 Priority AND 25% of the value pool? From my perspective, there’s a large difference. This feature is a much more significant portion of the value and requires particular care in execution. I hope you see the difference.

Minimal Marketable Feature (MMF)

Often in agile teams, singular stories don’t have sufficient mass or impact to effectively be valuated by the team or customer. Earlier I spoke in terms of themes of stories. This is a common way of bundling stories together that have value and meaning as a collection. Not only does it help in developing sets of meaningful functionality, but if you prioritize at the thematic or collection level, it simplifies your prioritization. It also has more meaning from the customers’ perspective.

A variation on this theme (pun intended) is the Minimal Marketable Feature or MMF. This concept originated in the Kanban and Lean spaces. Essentially, it’s the same as a theme, but it brings to bear the notion of deliverability, marketability, and overall customer usage.

Quite often an MMF is larger than a theme. It could be equivalent to a user story epic and require several sprints to complete. However, once complete, the team will usually physically deliver the MMF to the customer—for example, pushing it into the production environment.

MMF Driving Synchronization & Clarity

Lately I’ve been coaching teams that are struggling with their focus. There’s an anti-pattern that affects many teams where they start sprinting before they understand the business case and intent for their release(s). They’re delivering stories, but they don’t necessarily understand what the minimal set of functionality that their customers are looking for.

Not having this clearly understood becomes an impediment for them. Quite often their customers have an expectation of delivery that is quite different from what the team is delivering.

One nice way to connect the two back together is to establish a view towards the releases’ MMF. Part of defining the MMF is the round-trip discussions that occur as the teams’ estimates / sizes the stories within the MMF and the customer reevaluates whether they truly need that functionality given the investment of time.

This collaboration dove-tails quite nicely into release planning—as the team narrows into fitting the MMF into a specific release window.

I’ve even seen multiple sorts of MMF’s be developed for release planning—for example, a UX MMF that tries to capture usability and interaction flows vs. the cost of implementing them. Or similarly, an Architecture / Refactoring MMF that tries to guide these sorts of trade-offs.

I consider an MMF to be a necessary component of agile project chartering and release planning and develop them as part of any significantly sized or scoped projects.

Tracking Value

One of the wonderful additions to your tool-set as an Agile Project Manager is burning down (or up) the value of stories, themes, or MMFs. You’ll want to setup a burndown chart in a well visited location that burns down team delivered value. As with all burndown charts you’ll want to keep everyone’s eyes on progress and interacting with the team over progress and flow.

You’ll want to calculate total value for a release or project. Then setup your burndown on an iteration-by-iteration basis.

If you’re getting healthy agile behavior within your team, you’ll see value being delivered in a front-loaded fashion. You should also see healthy done-ness and quality attributes as these high-value features are delivered. In fact, I usually expect teams to factor in value as part of their overall quality and testing strategies.

Wrapping Up

Agile Project Managers don’t just care about by-rote execution of tasks or stories. No! Instead they focus their teams on a multi-faceted and nuanced view towards customer, value-driven execution.

Not only are they hoping to deliver value first, but they’re also hoping that by doing so, the customer may achieve a “good enough” view towards incrementally delivered product increments which allows the team to stop the project earlier than planned.

Stopping after delivering the features and functionality that truly matters the most to them. Sort of gaining their value and then moving onto their next highest value-driven project. It’s this sort of value-trimming that can truly make an agile team stand-out from their traditional counterparts and move so much faster. That is if stakeholders step out of their comfort zone and truly focus on value first.

Thanks for listening,

Bob.