The following is a fictitious example of the type of conversation that could occur at many organizations claiming to use agile development methods.
Joan is the VP of engineering at Trendy Startup, a rapidly-expanding company developing a suite of cloud storage products and services.
Joan's organization uses the popular scrum development process to develop its products. Product managers and owners create user stories, allocate them to iterations and releases, and manage them in backlogs. Quality assurance (QA) engineers write tests for the user stories, and developers implement the user stories. Team members meet daily to review the previous day's accomplishments, agree on what they'll do today, and surface any obstacles they are facing.
Joan is proud of her teams and their adoption of agile methods and practices. She touts the Trendy Startup's development processes to her fellow executives and to prospects and customers.
All members of her product teams have embraced agile methods, but two of her independent-minded engineers, Raquel and Oscar, are frustrated and have begun to question the results. They decide to meet with Joan to discuss their concerns.
Joan: "What's up, Raquel? Oscar?
Raquel: "We're concerned about our development process at Trendy Startup."
Joan: "Raquel, you know we're an agile shop. It's important that we all buy into agile practices, and frankly I don't think there's a place in our company for engineers who can't fit into agile teams."
Raquel: "Oh, I have no problem with agile methods. My concern is that I don't think we're really doing agile."
Joan: "Hmm. I'm not sure what you mean. We've adopted all the major practices, haven't we?"
Raquel: "Sort of. But what we call 'stories' are really just development tasks. We're not defining acceptance criteria for our user stories. And our product roadmap is oriented around features instead of what really matters to users."
Oscar: "Exactly! I'm frustrated because we seem to be losing sight of delivering value to customers. I actually don't care whether we are doing 'theoretically pure' agile, but we've gotten too far in the weeds."
Joan: "Ultimately, we can't deliver value to customers and be successful in the market without dealing with the details; things like font sizes, the positions of buttons and other user interface elements, and even grammar."
Oscar: "Of course. But we need to tie these details back to the larger picture of what the user is trying to accomplish as they are exposed to these details."
Raquel: "Right. That's part of what I mean about not doing agile properly. Many of the stories in our backlog are development tasks to 'move the Cancel button two pixels to the left'. But there is no tie-back to a real user story, which should state what the user wants to do and why she wants to do it."
Oscar: "I would go even further. Even when we do have real user stories, I sometimes lose sight of the big picture."
Raquel: "Good point! We've made some attempts to group user stories under features, but that's not how Mike Cohn says to do it. Cohn says to use epics and decompose them into user stories."
Joan: "But we do use epics. We group our user stories into epics such as 'asynchronous storage' and 'cloud infrastructure'."
Raquel: "But those aren't real epics! A story is a narrative. An epic is a long narrative. Look them up in the dictionary! In agile, a story is a placeholder for a narrative that achieves users' goals, and an epic is a placeholder for a longer, end-to-end narrative that captures and implements the larger goals of the users and buyers."
Joan: "Okay, I have to draw the line here. This organization doesn't care what the real definition of 'epic' is. We're not employing poets or novelists here. And in the final analysis, it doesn't matter whether we're doing what some purists think is agile. We care about producing quality software that will sell in the marketplace."
Oscar: "I couldn't agree with you more on those points, Joan, but I think Raquel has hit on precisely why the team loses the user perspective. Users care about what they're doing and what their goals are, not about 'asynchronous storage'."
Joan: "What would you suggest as an alternative? Can you provide an example of what you consider a true epic, Raquel?"
Raquel: "Here's one: 'As a gadget guy, I want to view and edit my documents from any device connected to the Internet so that I'm not dependent on any particular device for access.'"
Joan: "Okay, that seems to capture succinctly what the user wants to do, and the overarching value of our suite of cloud storage products. Your concerns are starting to become more concrete for me. Raquel, how do you suggest we modify our agile process to address these concerns?"
Raquel pulls up the following diagram from a Mike Cohn presentation on user stories.
Raquel: "Let's make sure we include real epics in our portfolio and product roadmaps. Let's decompose epics into user stories and include the user stories in our backlog. When we need to split a user story to fit into an iteration, our first instinct should be to split it by iteratively strengthening the acceptance criteria, not always by decomposing it along functional lines. All development tasks we include in the backlog should reference the user stories they support. Also, let's follow Mike Cohn's template for epics and user stories to ensure they are understandable to users and are verifiable. We can also group stories according to themes, but let's make sure the themes tie back to prospect problems."
Oscar: "Works for me! I really like the idea of epics standing for lengthy, end-to-end stories. They really tie everything together to show the value to customers and users in such a way that I, as a developer, can see how the details fit into the big picture. As a matter of fact, I've noticed a recurring pattern we could employ."
Oscar proceeds to draw the following diagram on Joan's whiteboard.
Raquel: "Pretty cool, Oscar. Your diagram shows a decomposition of an epic into smaller strories. The epic encompasses what the user ultimately wants to do and the unfortunate - but often necessary - system interactions that administrators must perform behind the scenes to enable the true value for end users. You've divided what we would need to implement into chunks our product owner could put in the backlog and our developers could complete in a single iteration. At the same time, none of the individual user stories by itself delivers what the end user needs. The top-level epic captures all of the stories playing out and satisfying the end user's needs."
Joan: "Now that you've explained them, these ideas make a lot of sense to me. We need to make this a team conversation and decision. I will fully support your starting this conversation with the team and proposing your ideas. I suggest a series of 'brown bag' lunches to discuss our process and possible modifications to it. Let's set the expectation that no decisions will be made at these lunches, but through open sharing of ideas and perspectives, we'll naturally converge on some improvements to our processes."