Skip to main content

BDD, Feature Injection, and the Fallacies of Product Ownership

Product Ownership is very difficult.  Take a big step away from the Agile Manifesto and think for a moment about project stakeholders, user stories, and how they don't fit together as neatly in real life as they do in Mike Cohn's User Stories Applied, as awesome as that book is.  How in the world is it possible for there to be a single person standing in for all project stakeholders in negotiating with the team?


Conveniently, Cohn himself points out The First Fallacy of the Product Owner.  And that is, of course, that such a being actually exists:
On an ideal project we would have a single person who prioritizes work for developers, omnisciently answers their questions, will use the software when it’s finished, and writes all of the stories. This is almost always too much to hope for, so we establish a customer team. The customer team includes those who ensure that the software will meet the needs of its intended users. This means the customer team may include testers, a product manager, real users, and inter-action designers. (User Stories Applied, p. 8)
As Cohn says, the Product Owner may in fact be a "customer team" of some sort.  And this team needs to somehow get onto the same page so that if the non-product-owners on the team have a question, they get only one answer, no matter who on the team they talk with.  Scary, but true, and very real life.  Can that be done?  Yes, certainly.  But it requires trust and discipline on the "customer team," and it may not come naturally at first.  And wait, there's more!

The Second Fallacy of the Product Owner is that the main people with whom the project must be concerned are the real users of the software.  Such a fallacy relies on a confusion between project "stakeholders/sponsors" and project "end users."  They are not the same!  What do you do in a corporate environment in which the "customer" with the budget is an executive decision-maker who will never use the software or even see it?  On real projects in corporate environments, your product owner needs not only to understand and manage the desires of competing software users, but also to build a consensus all the way up the executive chain of any sponsoring stakeholder organizations, and keep these sponsoring stakeholders as well as the end users (not to mention developers, testers, and other team members) all on the same page.  And of course business goals and user needs keep changing.  And that brings us to the related:

Third Fallacy of the Product Owner, which is that "business value" can be determined by operational end users.  Don't get me wrong.  Executives, and even some line managers, are the last people in the world you should go to, if you want to find out how software is used in the wild.  You will certainly build a big, unfortunate loser piece of software if you just listen to "the brass."  They don't know!  They probably don't even know all the systems their employees use to keep the business running.  You must listen to the real users of the software.

But if your goal is to deliver "high value" software first, and "lower value" software later, then the real users won't have the full picture either.  You need the executives to make decisions like "just skip that whole part of the old process--that never made sense."  And this begins to get very tricky indeed, because the "customer team" is now dealing with Stakeholder A who may be in a position to deeply change Stakeholder B's job, or even eliminate it.  So if you're under the impression that the "customer team" is one big happy family off in the "Product Owner room" all together, you need to let that go too.

So where do Behavior Driven Development (BDD) and Feature Injection come into the discussion?  My colleague Jeffrey Davidson just put together a brilliant slide presentation on these very topics, which you can see here.  BDD and Feature Injection are both methodologies which have been described as a step forward in terms of gaining a common understanding of system behavior between the "business side" of a team, represented by the Product Owner, and the "development side," represented by the developers and systems testers.  Because BDD and Feature Injection allow the system to be described as a series of examples, rather than a series of "the system shall" statements, business people focus on business value, and developers figure out the best technical way to get the business value out fast.

But BDD and Feature Injection provide something even more valuable, if you're being asked to be a Product Owner, or to be part of a customer team.  Both techniques provide a way to get real software users and executive stakeholders onto the same page, and to keep them there as well.  And that is a very good thing.

BDD, as Jeff says, is all about describing software in terms of examples, instead of in terms of the components that make it up.  (Please also see this timely repost of Martin Fowler's bliki post on "Specification By Example.")  "Given" a certain circumstance, "When" a certain real software user does something, "Then" you should see a certain result.  What does the Given/When/Then formulation do to help the customer team?
  1. High level user stories ("features" or "epics") described in terms of given/when/then give real software users a succinct view of how the software brings overall revenue to the firm.  You may also incur this type of benefit by revising the order of the traditional Mike Cohn style user story elements:  "As a <role>, I <need to incur a specific business value>, by <feature>."  Here the roles are far more likely to be executive roles like "as the CEO" or "as the CFO," but it's wonderful to know what it is that the team is building, in terms of the overall flow of revenue to the company.
  2. Low level user stories, the size that can be developed by the team, clarify to executive stakeholders exactly what real software users are doing and why.  Most normal executives cannot withstand even a single "the system shall" statement, but they may participate eagerly in a discussion couched in terms of "given/when/then," and be able to allay fears among the real software users that they have a specific need for some part of the system that is particularly obnoxious to use.  That's a good thing too.
What about Feature Injection?  Feature Injection, invented by Chris Matts, and explored in print primarily by Chris and fellow FI aficionado Liz Keogh, says that you need to start all software development discussions by talking in terms of the type of business value that makes sense to the CEO and the CFO. Chris and Liz will tell you that the team should be describing, with examples, what the new software will be doing for the business when it's done.  So the process is:  1)  identify the value, 2) identify the feature that will give you the value, 3) describe that feature in terms of examples.  Kent McDonald provides a nice, "gentle" introduction to Feature Injection here.

A customer team which combines Feature Injection to build word bridge between "value" and "features," and then describes those features entirely in terms of BDD's "given, when, then" scenarios may find itself aligned not only with software developers and testers, but also with itself.


  1. Thank you for the link to my presentation. I am super-excited about BDD and the sister philosophies of Feature Injection and Real Options.

    I am convinced this set of tools are a huge addition to the BA toolset. Using these, I can easily move the business from talking about solutions and features to real problems, allowing me and my team to address real business needs.

    It's a huge win for everyone when a development team is concentrated on solving business problems and adding value; BDD helps us get there.

  2. Yes, and your deck is really beautiful too! Thanks for getting that info directly from Chris Matts!


Post a Comment

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
WBABA: in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …