Agile Project Management—Driving Value or Where’s the Beef?

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. Often she was disappointed in her quest and shouts “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—then 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 solutions hoping to hit their 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.

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 value delivery.

A Prioritized Backlog!

One of the first mechanisms that drive value is the Product Backlog—the simple prioritized list that drives what agile teams are building. 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.

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 this distinction—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 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.

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 similar 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 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 customer. Earlier I spoke in terms of a theme 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 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 originates 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.

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 and allow 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.

 Don’t forget to leave your comments below.