Summary
In a recent series of conversations, Dan North, Martin Fowler, and Marc McNeill explore what is possibly the fifth Agile principle: valuing outcomes over features. They also discuss the differences between use-cases, user journeys, and features.

When a group of seventeen developers proposed in 2001 the Manifesto for Agile Software Development, they settled on four core principles of agile development:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

While there is value in the items on the right, we value the items on the left more.

In a recent blog post, Outcomes over Features - the fifth agile value?, Dan North proposed adding to this list a fifth agile principle:

Whilst there is value in delivering a list of features, I value achieving the outcomes of the project higher.

North takes issue with the practice of eliciting use-cases, or user stories, at the outset of a project that then lead to the creation feature lists. Those feature lists, in turn, become the yardstick by which a project's success is judged, often losing sight of a bigger, more important, picture—the project's desired outcome:

An agile project ... should focus on a set of outcomes. How we get there is less important than actually getting there. A CIO or business sponsor wants to solve a specific problem, by a specific date, and has an idea of how much money they are prepared to spend achieving that.

By driving out a comprehensive list of stories, estimating them, and then rolling it all up into a Big Release Plan, you run the risk of focusing attention on the features (stories) and defining success as the delivery of all these stories. This is exacerbated when the release plan is shown to people who weren’t part of the original exercise. They see the release plan and naturally assume that it is the primary "output" of the process.

North's comments come on the heels of a missive by Marc McNeill on customer journeys, Ditch the feature shopping list. Think customer journeys. McNeill's contribution to the debate of meeting a project's true goals is to point out a subtle, but important, distinction between user stories, or use-cases, and what he calls "customer journeys:"

Rather than thinking about vertical functional silos, we should think about horizontal slices through the functionality. Slices that support customer journeys. We can start with simple journeys to start and build complexity as we prove our process and new platform, mitigating technical risk as we progress.

Frequent use-case in online applications, for instance, is "account creation." This traditionally describes a new user creating a user account by entering a user name, a password, and possibly some optional demographic data. A use case-based approach would try to enumerate all the issues, or features, of account creation and management, such as providing a way to retrieve lost passwords, reclaiming inactive user names, and so forth.

By contrast, a user journey would start with, say a user wanting to reply to a forum post, such as this one. Clicking on a reply button, the system would prompt the user to either log in or to provide the information required in order to enable that forum post. While the latter may well result in the creation of a new user account, the user is seldom interested in creating a new account per se, but is more keen on just finishing her "journey"—post her reply to the forum.

The difference is subtle but important, according to McNeill:

Because we are building around customer journeys, just enough to realise customer intentions that support those journeys[,] we build only what is required. We are not building by feature list. We don’t over promise and under-deliver. We are building trust with all stakeholders.

Surely this is the better way to build software, thinking about customer intentions and incrementally delivering to support more complex customer goals. Sadly, people all too often get fixated by feature lists. Because that is what they are used to. Because that is how products are sold. But isn’t there a marketing 2.0 where we sell experiences and go beyond the product?

In FeatureDevotion, Martin Fowler summarizes the weaknesses of both use cases and features. Fowler agrees with McNeill's assessment of the dangers of letting use-cases flow into features list, which then define project scope:

The feature list is a valuable tool, but it's a means not an end. What really matters is the overall outcome, which I think of as value to the customers... Feature lists have another problem—you easily lose sight of the context that makes the feature valuable...

Use cases ... concentrate on a narrative of how someone uses a system... The weakness of use cases in planning is that they don't give you clear units to tick off so you can assess progress and project consequences of choices into the future. That makes them less useful as a planning tool, but that doesn't negate their value as tool for imagining what a good outcome would be.

A benefit of preferring to focus on outcomes over features is that an outcome may be satisfied by cutting scope on features, according McNeill:

Does “cutting scope” really mean failing to meet objectives? Or were those features not really core after all? A project has to have a goal, otherwise you can’t know when you’re done. This causes you to define “done” in terms of execution of the story list. Similarly, it has to have a feature list, or you don’t know what you’re going to do to get there. So it is just as big a risk to have no clearly defined outcome (i.e., no vision or purpose for a project) as defining a fine-grained feature list up front.

Next time you engage on a new project, make sure the entire team—and especially the sponsor—has a clearly articulated outcome for the project. And make sure you regularly review your direction to ensure you are still working towards those outcomes.

How do you figure out what to implement in your software project? How do you figure out how to divide that into iterations?

Talk Back!

Have an opinion? Readers have already posted 6 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market. Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.