Agile requirements are a key success factor for Scrum projects. Many people criticize the minimalist format of user stories, often forgetting that they are mainly a support for a conversation and don’t have the objective to fully document requirements. In this article, Paul Raymond discusses how classical use cases can be use to expand user stories during requirements elicitation in Scrum sprints.
Paul Raymond, Inflectra Corporation, http://www.inflectra.com/
User Stories are often characterized by relatively short, uncomplicated and informal descriptions, whereas Use Cases are often longer, more formally structured descriptions of not only the user need but also other details. Can Use Cases strike a balance between the need for agility and the need for more information, and if so, how?
Enough has been written about Use Cases in the context of Agile projects to save me having to restate the details here. For those of you wishing to refresh your memories, you can read about Use Cases and User Stories here on this site.
In outline, User Stories are often characterized by relatively short, uncomplicated and informal descriptions usually written by users or a product owner, whereas Use Cases are often longer, more formally structured descriptions of not only the user need but also other details including the participants (both people and systems), context, scope, exceptions, and end conditions. Consequently, Use Cases have a formality and level of detail that are not necessarily commensurate with Agile development.
However, Use Cases appeal to those looking for a way to record more information, or to organize the information obtained as part of the discovery process, something User Stories do not do well. Can Use Cases strike a balance between the need for agility and the need for more information, and if so, how?
Informal Use Cases?
A common suggestion is that Use Cases do not have to be so formal or detailed; in fact, they can be very brief and informal. The argument goes something like this, “If you start with minimal information, perhaps just the name of the goal, and write the detail just-in-time, you will still be Agile.” But if all we have is a goal, what makes it a Use Case?
Is an informal Use Case even a Use Case at all, or is it really a User Story? Very simple Use Cases look suspiciously like User Stories, e.g. The [actor] wants to [goal] so that [accomplishment]. So, let’s forget all the smoke and mirrors and call it like it is: simple, Agile-friendly Use Cases are User Stories. But this only leads to more questions. Can we use both? If we do choose to use both User Stories and Use Cases, who authors which?
And when?
Let’s start with the question that is often glossed over, ‘who writes what?’ If high-level Use Cases are written by the product owner, then who adds the detail when they are selected for an iteration? Some advise that the product owner should flesh out the Use Cases, but to do so would leave the development team with too little involvement in the discovery process.
Agile Requirements Management is a Team Game
It is an essential aspect of Agile development that requirements elaboration, whether via User Stories or Use Cases, is performed by the whole development team so that everyone, including coders and testers, have the chance to explore the problem space first hand. Of course, even if the product owner provides complete and detailed Use Cases, the development team could still engage the stakeholders to cement their own understanding; however, effort is then being duplicated, again undermining Agile principles.
Also, when the product owner provides full Use Cases, there is the risk of role separation, resurrecting the concept of departmental silos, which is not a very Agile concept. So, rather than one person laboring over the use cases, the team, including the product owner, should work together to discover the details of all the requirements.
A strong argument for User Stories is that their simplicity makes it easier to involve users, essential in Agile development. On the other hand, a strong argument for Use Cases is that they offer a convenient structure for recording essential detail. The first benefit is important early in a project and the second is important later. This difference supports the argument that says if you do want to employ Use Cases, it is better to start the project with User Stories and then develop Use Cases from them later, as part of each iteration.
Agile User Stories | Agile Use Cases | ||
Strengths | Weaknesses | Strengths | Weaknesses |
| Easy to write & change by users | Not so easy to write & change by users | ||
| Easily understood by users | Not so easy to understand | ||
| Unsuited to detail | Good framework for detail | ||
| Minimal documentation | Risk of too much documentation | ||
| Easy to include acceptance criteria | Less suited to acceptance criteria | ||
Summary: Ideal for backlog | Summary: Ideal for development | ||
One other argument in favor of User Stories is that they can convey things a Use Case cannot. For example, non-functional requirements such as performance or scalability are difficult to fit into the Use Case format, whereas the informality of User Stories makes such inclusions easier.
From User Stories to Use Cases
The conclusion is that Use Cases offer value to Agile projects, not as a replacement for User Stories but as a way to expand on them once they are selected for the next iteration. The available literature on the subject seems to focus on the problematic use of strict Use Case formats when in fact, the important point is not what is done, but who does it.
About the Author
Paul Raymond is a successful software program manager with Inflectra Corporation. He has extensive experience working with requirements management systems, including DOORS from Telelogic and SpiraTeam from Inflectra. Paul has helped customers in multiple industries take control of their requirements and develop actionable plans for the delivery of software projects on-time and on-budget. This article was originally published on https://www.inflectra.com/Ideas/Entry/281.aspx and is reproduced with permission from Inflectra.