Avoiding too many user stories in software development

In software development today, the overuse of user stories has become a common waste of time and resources.

Ellen GottesdienerEllen Gottesdiener

Today, the user story is often front and center in development projects, according to EBG Consulting co-principals Ellen Gottesdiener and Mary Gorman. That said, they are seeing development teams creating many unnecessary user stories, resulting in bloated backlogs, extra work to track them, and taking the team’s eye off of business value. Obviously, said Gorman, conversations about such project dimensions don't have to focus on the user.

In this tip, Gorman and Gottesdiener explain why and how to create just enough high-value user stories that contribute to an understanding of a project's requirements and end goal. They are co-authors of a recent book on Agile requirements methodologies, Discover to Deliver.

User story glut by example

The duo recently encountered a project manager who had 600 user stories in an application development backlog. All those user stories showed the team's extensive due-diligence work in a complex project that involved a platform change. Unfortunately, having so many user stories was a sign of no consensus on goals, a too-common occurrence EBG has run into in development projects, even Agile projects.

"This team had a fuzzy idea of the big why, the end game, and just started coming up with this plethora of stories," said Gottesdiener. Indeed, Gorman added, "It's not a contest to see how many user stories you can write. Not everything needs to be a user story."

Steps toward effective user stories

Mary GormanMary Gorman

A first step toward creating just enough user stories is delineating how user stories will and will not contribute to building and realizing business goals and objectives and deliver value to stakeholders. Too often project teams use only the user's perspective to rank the value of all product requirements. In this scenario, the team forgets to consider other product partners such as the business, compliance and technology perspective when prioritizing. The user may want to have the story realized in the next release, but it may not be the best option when weighting the value considerations of all the partners.

"You have to mix all of those perspectives when making decisions about which of the stories you're actually going to deliver or plan to deliver in your next delivery cycle," said Gottesdiener.

EBG often comes into projects where user stories have been created without a view of the planning horizon. Developers aren't clear about whether they're writing a story for two months out or the next development cycle.

"They're having story-writing workshops with quantity goals without a product roadmap in place," said Gorman. With all those user stories created, the team usually invests -- or "wastes," said Gorman -- time analyzing and slicing them. With a roadmap or at least a release plan, the team can create users stories as needed in a planning cycle and be able to refine those stories at the right time.

User-story prep for effective meetings

Preparing the appropriate user stories before iteration planning meetings is important. The consultants have seen teams come into meeting with stories that they haven't prepared for discussion and that may not be needed for an iteration. "They end up spending an hour or two on one story that may not be used in that iteration," said Gottesdiener.

A better practice is preparing users stories in smaller groups shortly before they need to be estimated and planned. "This makes the planning sessions much more efficient and puts the team in a good position to make estimates," said Gorman.

Managing user stories

User stories have a lifecycle. They can just be sitting in the backlog, but eventually user stories have to be explored and evaluated and confirmed. How do you know when you've met the acceptance criteria and finished with the user story? Gorman advises using scenarios, which are very simple examples, to organize user stories. Written in a narrative format, a scenario includes a headline or title, the given facts, the context, the event and the outcomes.

Scenarios are a bottom-up way to get stories into a concrete format. For instance, a customer places an order, but his credit limit has been exceeded and the order isn't completed. What happens? Does the company just accept losing that customer's order? Or can a business rule be created to provide other options for the customer?

"The specific example helps the team get to some of the dimensions around data, rules, etc., to be able to design and develop the solution," said Gottesdiener.

A top-down approach to stories may start with a minimal marketable feature (MMF), also called the minimum viable product (MVP) in Lean development. Often used in a flow-based model, like Kanban, the MMF is the smallest amount of functionality that can be delivered and still add value when independently released.

Prototyping is another means of discovering software requirements. In prototyping, a mockup of a solution is created. Prototyping can be powerful, because the solution can be seen in detail, said Gottesdiener. The drawback is that sometimes a team’s prototype locks people into a solution that may not explore all the requirements such as business rules and quality attributes.

Whether a development team utilizes user stories or other methods of gathering requirements, “just enough” practices are valuable. "You don't want to get into discovery paralysis and not be able to reach closure, make decisions and move forward," Gottesdiener said. Keep the short-term and end goals in mind to make user story scope decisions for the next delivery cycle.

Dig Deeper on Topics Archive