Developing Effective Agile Requirements Relies on Both User Stories and Use Cases


As the Agile movement continues to gain momentum and managing projects using Agile methods becomes more and more prolific, project professionals must become more savvy in their use of Agile methods. While the techniques and processes associated with Agile are different than those associated with Waterfall, many innovative project teams are incorporating non-Agile techniques into the Agile environment, with great success.

There is a common misconception that Agile replaces the need for use cases with user stories. Questions on this topic have been posted on social network sites such as Skillsharks, blogs, Twitter, Facebook, etc. The question shouldn’t be “Do user stories replace use cases?” Rather, the question should be framed: “How do we leverage the power of use cases with user stories when developing effective Agile requirements?”

Many shy away from use cases within an Agile approach because they resemble the ways of elicitation and analysis from the Waterfall approach. However, regardless of how one approaches requirements analysis, the end goal is the same: help business users/stakeholders identify their true needs and translate them into requirements. For Agile requirements to be successful, both must be leveraged to get to the heart of the most appropriate business solution that brings value to the customer.

According to Chapter 6 in the BABOK® Guide, “…business analysts prioritize and progressively elaborate stakeholder and solution requirements in order to enable the project team to implement a solution that will meet the needs of the sponsoring organization and stakeholders. It involves analyzing stakeholder needs to define solutions that meet those needs, assessing the current state of the business to identify and recommend improvements, and the verification and validation of the resulting requirements.” To be successful, a business analyst needs to have strong facilitation, information elicitation, and process design skills. These are the core elements to building effective use cases.

Developing Effective Agile Requirements Relies on Both User Stories and Use CasesIn Agile, requirements are progressively elaborated. Each iteration or sprint allows business users/stakeholders to better define their needs to ensure the most effective development of solutions. These iterations or sprints rely on the user stories that the business user/stakeholder “tells” to concentrate on features that users value and interact with directly. These short scenarios of user expectations are just part of the user story process. User stories include two additional elements:

1. Notes from further discussions about the story that help to clarify the expectations (Conversation)

2. Intent of the story and validation tests that will confirm to the user that the story, when delivered, does what it is expected to do (Confirmation)


Before the Agile team begins to collect the detailed requirements that describe the features of the system, it is vital that the overall vision and purpose of the project is identified. This also includes the product vision. The product vision acts as the boundaries of the project in which the iterative, incremental work takes places. The product vision should answer the following three questions:

2. Why is the product useful?
3. What features will attract customers to this product?

This is the first place we begin to see the power of integrating user stories that are being gathered with the elicitation technique of use case modeling. Figure 1 is a graphical representation of how we see use cases being leveraged during this process.

Setting the product vision from a requirements perspective is the most important element when building a solution. This sets the parameters to ensure that we deliver what is needed as well as marks the end point when it comes to tracing requirements.


Use cases are diagrams that demonstrate the actors and their goals. Actors are typically people or systems and the goals are what the actor is trying to achieve. Use cases in Agile help to define who needs to do what with the system and begin to identify the business value of that interaction.

WHY AND WHEN TO USE USE CASES IN AGILE?On Agile projects, it is typically best to leverage the power of use cases not only from the project perspective, but also the product. From a project perspective, it is a great way to demonstrate, in a visual and easy to understand format, the scope of the ‘who needs what’ for this project. From the product vision perspective, it is also great for starting to envision requirements of a system that is user driven as well as to identify Themes and Features.

In Agile, there are four levels of requirements. Themes are used to describe larger requirements that may include multiple features within it. Features are a collection of related stories. These two levels offer a great opportunity to use use cases because they can provide a simple visual representation of the product scope and allow for improved prioritization of the requirements. The other two levels are a bit more detailed and are known as Epic and Story. Epic is used to describe a Story that is too big to get done within an iteration/sprint and needs to be broken down into smaller chunks. Finally, Story is the smallest valuable business requirement that follows the INVEST attributes.

Effective Agile requirements rely heavily on use cases and user stories. Remember that user stories focus on the features that users expect to be available when they use the finished product. They are meant to express short scenarios of user expectations that help business analysts on an Agile team dive deeper into connecting those expectations with delivering the appropriate solution value. Use cases are used to help with the value analysis for the user, thus enabling appropriate prioritization of the product backlog.

There is no set prescription on when exactly to use use cases and user stories. Both are required to help prioritize the product backlog and both are used to better understand the customer need and where the customer places value on what needs to be delivered. Using use cases and user stories is needed on Agile projects, however the timing of when to leverage them is dependent upon the type of Agile project that the team is working on.

Author: Nancy Y. Nee, PMP, PMI-ACP, CBAP, CSM

Nancy Y. Nee, PMP, PMI-ACP, CBAP, CSM, Vice President, Global Product Strategy, ESI International, guides clients in the development and implementation of learning programs customized to their specific needs. Her solutions reflect the insight of almost two decades of PM and BA experience in healthcare, information technology, financial services and energy.

Like this article:
  26 members liked this article


sumit.soni posted on Monday, June 17, 2013 1:17 AM
Helpful for Agile Practitioners..Very informative. tnx for posting..!!
David Wright posted on Monday, June 17, 2013 12:13 PM
I was hoping for more. You describe what the pieces are but not how they are used together. Can you offer more detail?
Tony Markos posted on Monday, June 17, 2013 2:25 PM
With both Use Cases and User Stories proper partitioning (coming up with right size and equal size chunks of required system behavior) and the avoidance of excessive complex dependencies supposedly happen via "Black Magic": Neither technique offer any guidance to along these lines.

Suggestion: Read about how Data Flow Diagrams uniquely actually guide a BA in performing an interface (ie dependency) analysis, leading to a logical, natural partitioning, enabling an effective decomposition to handle complexity.
J.Zelinski posted on Tuesday, June 18, 2013 1:23 AM
I see that Agile is strong product centric, IMHO many agile projects failed because agile people can't see business problem. Business need solution but not "product"... it is the little different.

About use case: If we mean "user story" is the same as "informal use case" I agree... What the difference between feature and use case and story? I don't understood... We have use case (in UML) as "system service for the actor", we can documents scenario as text (informal) or as sequence (formal). I scenario was write by the user, we have user story...
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC