The Nasty Effects of Mis-Using User Stories in Agile Projects

Just how important are user stories in agile projects?

In prior blogs, I address causes of software project failures. Mis-managing requirements generally is the biggest cause of project failure, and identifying requirements errors later in the project exponentially increases project cost. Not using agile methods or selecting the wrong agile method for your project’s situation are other causes. This blog address agile requirements – specifically, the mis-use of user stories.

User stories are ubiquitous in agile projects, and some agile practitioners even feel that projects without user stories are not agile. In fact, user stories have their place, but they can be mis-used, causing requirements errors that can impede or kill projects.

How to write a proper user story

Good user stories are simple, clear, brief descriptions of functionality that a customer will find valuable.

They usually take the form of: “As a <Type Of User>, I can <Action/Function>, so that <Objective/Goal>.

Each story should be independent, negotiable, valuable, estimable, small and testable (INVEST).

‍

In practice, each involves the three Cs:

• the card (paper or virtual)
• the conversation (with the Product Owner)
• the confirmation (acceptance tests).

The card is created when the idea first emerges; the conversation happens when the Product Owner wants the team to implement the requirement; and the confirmation happens during execution prior to release. User stories are famously referred to as a “promise to talk later about the requirements.”

A prior blog, “Select The Right Flavor of Agile to Succeed,” emphasizes the strengths and weaknesses of various agile methods, and the importance of selecting the appropriate flavor for your project. The same is true for agile requirements. A user story is always better than no requirements, and almost always better than “shall” statements. But there are situations where use cases are superior to user stories.

What exactly are those situations?

To answer that question, you must first be able to answer the following:

• Is your project a “green-field” application or maintenance of an existing application?
• How many stakeholders are driving requirements?
• Are they in one or many departments?
• Are they located in a single facility or span the globe?
• Are there multiple variations of the same type of user?
• Are stakeholders collaborative or adversarial?
• Will changes in one set of requirements prompt changes to another set of requirements?
• Do “outside” organizations need to understand your system’s requirements to integrate with it or to otherwise understand it?
• Is your regulatory environment such that your requirements, design, coding and testing could be scrutinized later?

‍

In which cases might a user story not be appropriate?

User stories are not good for software development projects with many, far-flung stakeholders in different departments in different time zones with divergent interests – especially for “green-field” applications.

In addition, User stories alone aren't sufficient enough for anyone to truly understand the totality of a system's functions and the way a user interacts with the system.

So when you have numerous, distributed stakeholders, it is very difficult to gain agreement about how the system should actually work. And if the stakeholders can't come to this agreement, it can lead to requirement errors that cost time, money, and threaten the project.

In such conditions, the three Cs are actually an “F”. In such situations, use cases are superior.

A use case is a sequence of actions performed by the system providing an observable result of value to a particular actor. Similarly, a visual use case model shows the totality of needs, and their relationships to each other and to various types of users.

The text of use cases facilitates understanding of the proposed functions, order of interaction, and business rules of the system in clear, unambiguous terms that all can understand no matter their location, time zone or bias. And they are fast and flexible – I write a basic use case in less than five minutes, and write full use cases usually in about an hour – easily fast enough to stay ahead of any development team.

Even better, because use cases succinctly provide better information, I can gain consensus on requirements from many stakeholders far faster with use cases than with user stories – while also greatly reducing the risk of costly and time-consuming software re-work later on.

And the best part is that the structure of use cases enables one to start with a user story and, as needs demand, elaborate the user story into a use case. The initial user story can substitute for a Use Case Summary. If and when conditions dictate, one can add the basic steps, the actors, the pre-conditions and post-conditions, alternative flows, and supplementary requirements (business rules). This is the kind of on-demand flexibility that appeals to all Agilists.

This is part of a blog series in which I explore key reasons why software projects fail and provide actionable remedies to root causes of failure. Hopefully, you may find the series informative and relevant.

Read the previous blogs:

Why Do IT Projects Continue to Fail?

‍Select the Right Flavor of Agile to Succeed