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?
- 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.
- 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 Injectionhere.
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.
This post is from Pragmatic Agilist by Elena Yatzeck. Click here to see the original post in full.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.