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.
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 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:
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:
Proactive means to intuitively learn from events in the past, understand how they impact delivery and warn that a repeat event may occur shortly.
The causes of failure in software projects are extraordinarily well documented.
As technology advances, mainframe organizations are increasingly pressed to transition to more modern platforms. Here are some of the most common misconceptions that hinder their mainframe modernization journey.
The cost of not modernizing mainframe systems is generally far greater than the time, effort, and money required to make the transition. Here's why.
As mainframes host mission-critical applications, it's essential to ensure that the modernization process is accurate and causes minimal disruption to business operations. This is where automated migration and testing tools come in.
Get in touch with our experts and find out how Astadia's range of tools and experience can support your team.contact us now