Confusing features with value

Understanding the feature trap

“Surely there comes a time when counting the cost and paying the price aren’t things to think about any more. All that matters is value – the ultimate value of what one does.”

– James Hilton

The Feature Trap

I believe there is a fundamental misunderstanding in the agile community today. I’ve seen it happen when we attempt to do release planning over several iterations. As we build out our backlogs full of assumptions about what customers want, we start to tightly define what a team should deliver. When we do this, we fall into a trap of tightly associating features with value delivered to the customer.

 

The problem is that a feature (or epic, or whatever you call a big story or aggregation of stories) isn’t really a unit of customer value. “Wait a minute!” You say, that’s exactly what a user story or feature is – it’s right there in the definition! Well, I disagree. A feature, or user story, or frankly any kind of information we get from customers, product owners, business analysts or anyone else, is really just a hypothesis about what might be valuable. We don’t really know if it’s valuable or not yet. We may suspect we know. We maybe awfully gosh-darn sure we know. But we don’t really know until it gets in the customer’s hands and they actually use the product.

 

Here’s my central thesis: User stories, features, and epics are the language we use to convey our understanding of what we think customers would find useful to teams. It’s intentionally vague because there is lots of uncertainty in making these sorts of assumptions or guesses. But make no mistake, these things that we give to the team are riddled with our own assumptions and guesses about what the customer wants or needs. These crude tools are the inputs to our planning process. They are not an output. They are not value.

The Team’s Dilemma

Why is that a problem for teams? Well, if what we are giving teams is not a definition of actual value, but rather a hypothesis of what might be valuable or useful, we should not tie their performance to the delivery of said guesses. What teams do is translate this language that we have given them into working software that someone may then use. A lot changes in that translation. Interpretation takes place, and yes, even some learning. If this is true, then the software that eventually pops out of our software “Easy Bake” oven is going to be different than what we asked for. It must be if we have any hope of getting reasonably close to what a customer needs.

 

But what do I see happening? Teams are told that their success will be measured by their ability to deliver the features that were requested! Wrong! Dead wrong! I don’t want the team to simply process and regurgitate whatever assumptions they were given. I want a team to try and understand what was given to them, I want them to test it out against the customer’s needs, I want them to interpret the results and learn from them, and I want them to deliver something that most closely meets the customer’s needs, not what whatever crude artifacts were handed to them at the beginning of their planning process.

Whack-a-Mole

What if I asked for a “Mole whacker?” If I ask for that and you just stuck to my description, I’d probably end up with a stick. That’s not what I need. I need a giant rubber mallet for proper “Mole whacking”. How do you know that? By whacking moles of course. So, we need to stop holding teams accountable for just delivering features. That is simply getting it all wrong. What we need to do is to ask them to interpret their understanding of the inputs we have given them, and to articulate some idea of what they think the value will look like. In SAFe this is called the PI Objectives. Me? I call it value or customer need. Tell me what value you think you can deliver. That’s what I’ll expect to get from you. Is it a guarantee? No. It shouldn’t be. It’s a statement of what we know now and a commitment to learn more so that we can deliver the best possible refinement on that value that we can manage in that time box.

 

Ultimately, it’s not product, management, or anyone but the customer that will define what value is. We will make our guesses using the simple tools that we have to articulate what we think that value might look like. We will ask the team to interpret that language and then deliver the best possible implementation of that value that they can. That’s what we ask for from the teams. We don’t ask for features at the end of the day, we ask for value. Features are not value. They are simply a guess, a way of articulating what we think the value is. Teams consume features when they plan and deliver value.


Tom has been working as a transformation agent in software development for over 20 years.…

Comments

rewrite

Insights from the app driven world
Subscribe Now >
RECOMMENDED
The Sociology of Software >How (Not) to Lie with Data Visualization >DevOps and Cloud Computing: Exploiting the Synergy for Business Advantage >