Tuesday, 04 March 2014 10:59

User Stories and Use Cases - Don’t Use Both! Featured

Written by  Shane Hastie & Angela Wick
Rate this item
(42 votes)

We’re in Orlando for a working session as part of the Core Team building BABOK V3 and over dinner this evening we got to discussing the relationship between user stories and use cases (it wasn't the only thing we discussed, we are also a social group ;-)).

We noted with concern that there have been a number of recent discussions (client, articles, blogs and general industry) of using both User Stories and Use Cases at the same time in Agile projects. This seems to us (with general agreement around the table) to be both a waste of effort and actively against the Agile philosophy of doing the simplest thing that will work and deferring the detail until just ahead of when the component of the product will be built.

We would like to outline the basic differences, considerations and risks of using this approach. Even it is seems to be a trending topic, we would like to fill the gap in addressing beyond the trend and move towards the practically and risks of using Use Cases on Agile projects.

Differences and Similarities

So what are the differences and similarities between User Stories and Use Cases, and when do we recommend using the different tools?

Use Cases

A Use Case is "an end to end sequence of interactions between an actor and a system that yields a result of observable value to an actor, usually the instigating actor". Um, so what does that actually mean? Generally a Use Case (the textual description, not the stick figure diagram) is written as a flow or sequence of steps in the format

Actor does something
System does something
Actor does something else
System does something else
...

A Use Case is made up of one main flow and a number of alternate and/or exception flows some of which can branch back to the main flow.

Now Use Cases are by nature fairly detailed - they describe the steps in an activity and the points in the flow where things can change. To produce a useful (can be given to someone to build from) Use Case you need to define the set of interactions in quite a bit of detail, you need to understand what the business rules are that govern the activity, the options that the actor will have available to them when undertaking the activity, the ways things could go wrong and what bits of information are needed in the flow of interactions. To do this you need to spend quite a bit of time and effort analysing the activity and producing the document. This is BDUF - Big Design Up Front which is the antithesis of Agile.

User Stories

User Stories were originally a reaction to this big up front thinking. When Kent Beck defined eXtreme Programming (XP) he came up with the concept of a User story as a tool to support the iterative and incremental approach which is inherent in all the Agile methods. Mike Cohn went on to write a book which explained what User Stories are and how they are used in Agile projects. In addition to these two, Jeff Patton publicized the technique of Story Mapping to show how User Stories can be used to cover the breadth and depth of functionality needed in a product.

The key to writing good User Stories is to understand that the intent is not to provide the detail early on in a project, but to provide a framework where the detail can be added as it is needed, just enough and just in time. Drawing on the work of Beck, Cohn and Patton and many others the generally accepted approach to producing User Stories and using them to guide the development of the product follows a decomposition approach.

The decomposition comes in the form of a story map. The beginning of a story map is defining the Backbone stories – the key User Activities or Tasks which need to be accomplished to do the work of the product, the large discrete chunks of functionality which need to be delivered to be able to say we have solved the problem. These large chunks are often referred to as Epics (a big story ;-)), they equate to an elementary business process, something that is done in one place, at one time, by one person. Comparing this to Use Cases, this would be the result of the Use Case survey - a list of the discrete elements of the product, goals of the actors.

When building a story map, these Epics are normally laid out in a single row showing the logical sequence and handoffs between the steps in the process. Visually these Epics will be written on a different colour card to t e User Stories which will come later.

wick mar4 2Image: An Example of a Story Map – Epics in green along the top

Epics can be put in sequential order along the top (if sequence is appropriate, which it normally is).

The next step in the Story Map is to populate the map with the User Stories that fall under the Epics. Each User Story is a small, discrete piece of functionality that has value to some user of the product and is a decomposition of the Epic above. The most common format for writing User Stories is "as a (role) I want (feature or capability) so that (business value to be delivered)" -

  • As an internet banking customer I want to list my account balances so that I can understand my financial position.
  • As an internet banking customer I want to list transactions on an account so that I can check the detail

The three elements are important - knowing who the story is for helps ensure we build a useable product, what the functionality is that is needed and the value which will be derived from having that functionality enable us to make good priority decisions.

Priority based on business value is very important to defining User Stories. Knowing the value from a story enables us to make good decisions about the sequence of work - building the most important business value components first and getting feedback early rather than trying to build everything at once is inherent to Agile.

The User Stories are the orange cards in the image above.

Priority and Sequence Shown in the Map – identify the MVP

One of the benefits obtained by building a Story Map that shows the logical flow of activities (from Epic to Epic along the top) and the discrete elements of those Epics vertically down the page is the ability to clearly see both sequence and priority. Stories that are higher up on the map are more important (needed sooner) than those lower down.

The prioritisation and sequencing approach enable the discovery of the Minimum Viable Product (MVP) – those elements which need to be delivered to provide the opportunity to learn and adapt the product based on feedback from real customers/users. Finding the true essence of the product and getting that into the hands of real customers (probably just a small subset initially but enough to get feedback to validate the assumptions being made in the development of the product).

In a real-world internet banking example, the very first version of the product which was put in production had the ability to log in and to list balances and this version was used by the project team and a small group from within the bank. Having this “walking skeleton” built and put into production validated the architecture of the product, identified a number of unexpected challenges with the deployment process and gave the team feedback about their design philosophy which enabled them to make some significant changes when they were cheap and easy to do.

The Elements of a User Story

In his book, Mike Cohn says that a User Story has three C's - the Card, the Conversation and the Confirmation. The Card is the initial User Story, written on an index card or PostIt note. This is deliberately short and devoid of detail. The intent is to defer the detail until later in the project, just ahead of when this piece will be delivered. The detail is established through the second C - Conversations. As the project progresses and elements are delivered there will be a number of conversations that result in clarity of understanding about what is actually needed to deliver the value identified in the User Story.

The final C is Confirmation - these are the Acceptance Criteria for the User story - the details which will enable the customers and the technical team to agree that "if this story meets these criteria it is done". This is the detail which is all too often left out in bad Agile projects (“Tragile”). This detail needs to be agreed to, and it will contain whatever is needed to enable the delivery of this component of the product. The key difference between Agile and other approaches is when we produce this detail. In an Agile project this will be produced collaboratively with the customer representatives just ahead (a couple of hours to a couple of days) of when the piece will be built.

The most common format for these acceptance criteria is the <given><when><then> structure of Acceptance Test Driven Development. Each user story will have a number of acceptance criteria and may also have other elements which will help ensure the right thing is built - these could include screen mockups, technical notes, models such as class diagrams and whatever the team needs to enable them to deliver the business value.

Examples (for the list account balances user story)

Given the customer has one credit account and one savings account
When they have logged in successfully
Then the two accounts will be listed in account number order (Account no, Name, Balance, Available Funds)

Given the customer has no accounts
When they have logged in successfully
Then a message indicating that there are no accounts to show will be displayed

Given the customer has twenty one accounts
When they have logged in successfully
Then the first twenty accounts will be listed in account number order
And a Next Page option will be enabled

Given the customer has twenty five accounts
And they have logged in successfully
And they are on the first page of the list
When they activate the Next Page button
Then the list will be cleared
And the list will be populated with the last five accounts
And the Previous Page button will be enabled
And the Next Page button will be enabled

Gojko Adzic's book Specification By Example provides an excellent reference on how and when to produce acceptance criteria.
Ultimately the Acceptance Criteria will be proven through a set of test cases (ideally automated) which show that the product works as needed to deliver the business value.

Reduce Waste and Be Responsible

Again, the key to reducing waste and rework is to defer this detail until just ahead of when it is needed, rather than trying to clarify it all up front. Things will change over the life of the project and deferring the detail makes it cost-effective to adapt to this change.

However – taking this just-in-time approach is not an excuse for poor architecture or bad design. Early on in the product development it is important to set clear architectural guidelines, design principles and deal with what Philippe Kruchten calls the “Architecturally Significant Non-functional Requirements” – those aspects which will be extremely expensive and difficult to refactor later. Note however that we say “guidelines” and “principles” – don’t try to build the complete architecture up front, allow it to be emergent inside the boundaries of these clear guidelines.

Traceability in User Stories

Hopefully it is clear from this description that User Stories actually have a powerful traceability mechanism built into the design of the technique.

There is a cascading one to many relationship:

  • A Role or Class of User derives value from one or many Epics
  • One Epic could have many User Stories
  • One User Story will eventually have many Acceptance Criteria
  • One Acceptance Criterion will have multiple Test Cases which prove it is working as expected

This traceability is enacted through the “so that” component of the user story, which ensures that every piece which is implemented has a direct relationship to the business value to be derived from that component/capability.

Timing Makes the Difference

The key is the timing - User Stories are deliberately abstract early on in a project and will evolve over time on a just-in-time and just-enough basis. This is because Agile projects expect and anticipate change and respond to this change by adapting the product to the evolving needs. More User Stories will be added, some will be dropped and our understanding of many will change as time progresses. The reality of today's business world is that change is inevitable, so trying to define the detail of all aspects of the upfront will result in lots of wasted effort and time as much of the work will need to be redone.

The Story Map is a fluid and changing tool – as stories are completed they are removed, new ones added and change is accepted as a normal part of the way we maximise the delivery of value to our stakeholders and the organisation for whom the product is being built.
The detailed Acceptance Criteria for any User Story will on be produced just ahead of when it will be delivered, maximizing the amount of work not done (one of the 12 principles of the Agile Manifesto)

One of the mistaken and dangerous myths of Agile is that “Agile projects have no documents” – the reality is Agile projects have the documentation that is needed to ensure value is delivered, and nothing more. The philosophy is to defer work until just ahead of when the output of that work is needed (a concept inherent in Lean thinking) and only do that work which is necessary to achieve the desired outcome (preventing waste from unnecessary effort and rework).

This is in stark contrast to Use Case thinking where the goal is to define in the various flows of the use case all the detail of the requirements up front. This approach will inevitably result in wasted effort as the use cases will have to be maintained and updated as the changing needs emerge. In agile we want to evolve the solution iteratively and incrementally as we learn based on feedback from real customers/users, not rework the documentation and requirements.

Could you use Use Cases instead of User Stories in an Agile project?

Theoretically Yes – you could indeed use Use Cases instead of User Stories to express the business needs. None of the Agile approaches are prescriptive about how you express the list of capabilities/features the product must contain (what Scrum calls the Product Backlog), however we see significant risks in trying to do so. Use Cases miss the mark on the “WHY”; they are not well suited to expressing the separate pieces of business value and supporting the iterative, incremental approach to developing the product – they tend to be monolithic and encourage an “all or nothing” way of thinking vs. an adaptive evolutionary style of learning and discovering the solution together through quick build and feedback loops.

Could you build Use Cases after developing an Agile solution to document the requirements after the fact?

Theoretically, yes . . . however with this approach you have missed out on a critical technique in User Stories to guide conversations towards maximising value and minimising extra work throughout the development process.

Risks and Dangers of Use Case Thinking in Agile Projects

  • Compromised Innovation
    • Use Cases bring on a lot of detail before getting feedback on a built product. This cognitively brings user mind-sets into a predefined interaction and solution, negating the potential for further innovation. The exploration and learning aspect is compromised and focus goes from solving a need to perfecting an already defined solution.
  • Compromised Timelines:
    • Too much detail before building compromises the benefits of time in the Agile approach. Spending time detailing out Use Cases is spending time on what and how when we be should focusing on the why. Defer the what and how until just ahead of when it is needed
  • Compromised Value:
    • Use Cases confuse the role of Acceptance Criteria in User Stories and agile. Many teams are using Use Cases as an alternative to creating Acceptance Criteria for their User Stories. Acceptance Criteria evolve in levels of detail as builds iterate and evolve and more is learned together through the agile process. This learning process is where the value lies as the needs are quite unknown before starting.

Conclusion

Many teams embarking on their Agile journeys are finding comfort in techniques used in the past for requirements definition, particularly Use Cases. Use Cases resemble user stories in more detail, and User Stories were developed as a condensed technique to alleviate the lack of WHY in Use Cases and to alleviate too much detail too soon when using an Agile approach.

We believe that User Stories and Acceptance Criteria are the techniques aligned to deliver the benefits of the Agile approach and Use Cases compromise and put the benefits of the Agile approach at risk.

Teams thinking about using Use Cases should strongly consider looking at the methods and evolutions of defining Acceptance Criteria (especially the <given><when><then> model) with many scenarios and levels of detail that evolve as feedback through the iterative cycle and delivering increments of the product as it evolves. Keeping with user stories (Including story maps & epics) along with well defined and evolving acceptance criteria will meet the goal of leveraging the benefits of agile without putting timeline and value at risk.

Don't forget to leave your comments below.

About the Authors

shane hastieShane Hastie

Shane is the Chief Knowledge Engineer and Agile Practice Lead for Software Education, a training and consulting organisation based in Australia and New Zealand, working all around the world. 

Shane teaches courses and consults around business analysis and agile and is passionate about bringing the two communities together.
He is a member of the board of the Agile Alliance, and is the lead editor in the Process and Practices community on InfoQ.com
He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it. and on twitter as @shanehastie

awickAngela Wick, CBAP, PMP

Ms. Wick is passionate about inspiring innovative BAs and is a leader in the business analysis field. Angela is a trainer of business analysis, project management and in bringing innovation and creativity to these roles. She enjoys working with traditional and agile teams, and especially in preparing teams for agile in their organization. She also consults with organizations in building BACoEs, BA practices, BA Career Models, and BA competencies. Angela is a lead contributor to the BABOK v3 and the IIBA Competency Model. Angela is also a monthly blogger on BaTimes.com

Angela can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it. and on twitter @WickAng

Both Shane and Angela are Core Team members for the IIBA team building version 3 of the Business Analysis Body of Knowledge (BABOK)

Read 22950 times Last modified on Tuesday, 01 April 2014 07:23

Comments  

+11 # Jenny Quillian 2014-03-04 13:07
Your analysis assumes a narrow version of the use case where "the goal is to define in the various flows of the use case all the detail of the requirements up front". I think that use cases have evolved beyond this, and can now be adapted by team or by project needs in order to form and communicate requirements, rules, and constraints between the stakeholders. User stories can be the start of a use case, and if done well are much more palatable to read than a long list of < this>< then> statements.
Reply | Reply with quote | Quote
0 # rosebud 2014-03-11 16:01
Agree Jenny ... the user goal is the first stop in developing a use case, as it should be for any process modelling technique. The authors also underplay the value of use cases in requiring the stakeholders to think about scope, and the needs (values) for multiple stakeholders within one transaction.
The definition put fwd for MVP is also interesting. Maybe it should be called MVD: minimum viable design :o)
Reply | Reply with quote | Quote
+5 # Kent McDonald 2014-03-04 14:14
Generally, I agree with Shane and Angela's advice about not using both use cases and user stories.

I mostly agree because I have never found use cases as particularly helpful in the types of projects with which I have been involved. That said, I know there are (several) teams out there that do find use cases useful and helpful.

Since user stories by themselves are helpful but insufficient for describing a solution, teams I work with tend to supplement stories with models, acceptance criteria, and examples.

Use cases are one type of model. If your team has used use cases, found them helpful and effective, go ahead and continue to use cases to help further explain the stories - if the team continues to find them helpful and useful. If the team finds they are doing extra work by creating use cases that are not helpful, stop using use cases.

In other words, simplify and do only what makes sense and contributes to satisfying your stakeholders needs. In most of the situations I have found myself in, that usually does not mean doing both user stories and use cases. Your experience may vary.
Reply | Reply with quote | Quote
+4 # Jill House 2014-03-04 14:17
While I prefer environments using 'user stories' over those using development styles using 'use cases', in my experience I have found organizations that attempt to implement an agile approach with user stories without understanding how the whole process works. Also I find that users are very nervous about just giving high level needs without the ability to also express at the same time the exceptions to the need. Also I've found users become irritated when you continually come back to them for the next layer of detail. Granted that is an organizational change that needs to take place; but the reality is I've experienced several IT organizations giving up on Agile before it was fully embraced by the organization for that very reason.

I have been fortunate enough to work with one organization where the agile methodology was used very effectively. However, that business was not highly diversified and did have true product owners who possessed a vision to describe where they wanted to go as well as related it to limitations/reg ulations that may exist so that it was a realistic vision. There are very few people with that skill, and having a strong product owner or business owner or SME - -whatever you want to call it, is an absolute must for success in Agile.
Reply | Reply with quote | Quote
+6 # Greg Smith 2014-03-04 15:19
Shane and Angela, what a deep article! You gave so much more than use case. You covered about 1/2 of an Agile lifecycle, nice work!

Two quick thoughts based on my experience:

1) The article assumes use cases are all done at the start. In 1997 I worked with a team that did iterative releases every 6 weeks, and we only listed use case titles at the start of the project (very close to a story) and then we did JAD sessions (Joint Application Design for younger folks :-)) at the start of each release and added the detailed scenarios right before each use case was to be coded. This model kept us implementation agnostic for early planning, and then allowed us to get into the details when it was time to build. So no repercussions to an agile approach and we still used use cases.

2) I have been using BDD and ATDD for many years now, and from my perspective the goals of given/when/then are identical to a use case (preconditions/ steps/post conditions). As a matter of fact, I tell students that they are identical when we do training. However, I tell them, just like you have, that we should not take the story to that level until just before construction begins.

So, from my perspective the best Agile teams today are doing use case work (ATDD) they are just calling the attributes something different, and not doing the use cases until we are close to time to build. The use cases are children of the stories.

Thanks! Greg
Reply | Reply with quote | Quote
+5 # Arnold 2014-03-04 17:38
Maybe the authors haven't heard yet about Use Case 2.0. It's agile and goes hand-in-hand with user stories, the very opposite of what the article is advocating.
Reply | Reply with quote | Quote
+7 # Elizabeth Larson 2014-03-04 20:06
I think one of the wonderful things about Agile is that the team has the wherewithal to choose techniques that work best for them. So I was surprised at the admonition not to use use cases and user stories. It seems to me that the implied inflexibility, while well-intentione d, is misdirected. So why are use case narratives helpful on Agile projects? They provide a way to structure our thinking to more quickly arrive at acceptance criteria. I love acceptance criteria, but it is simplistic to think they are easy. Sure the format is easy—given one or several conditions (use case pre-conditions) , when I do something (use case actor action), I expect certain results (use case system response). But the thought process to determine these things is not easy and takes a great deal of thought and discussion. I believe that use case narratives are the surest way to get solid acceptance criteria needed to estimate the user story during sprint planning and then build it during the sprint. Perhaps, though, they don’t work for everyone. I think that if use cases are helpful to the team, use them. And if they don’t work for the team, use other techniques. But let’s not dictate which techniques the teams should or not use.
Reply | Reply with quote | Quote
+1 # David Gelperin 2014-03-05 00:13
The strength of use case modeling is in describing complex flows e.g. making an airline reservation which includes searching for acceptable flights (fares and times), selecting a seat, buying insurance, identifying chargable luggage, and paying for the flight. There are a few ways to succeed and many ways to fail. User value is in the entire flow, not the pieces.

The authors describe the development of use cases as BIg Design Up Front. While it may be big detail or big analysis, it is not big design and, as already observed, it does not have to be upfront. In complex situations, big analysis is required.

Also note that estimating a user story for a complex situation prior to analysis is an act of blind guessing unless the estimator has experience with the specific complexity.

A single pre, post, and trigger condition model is inadequate for the reservation flow. When multiple sets of conditions are needed, using a wordy textual description, rather than decision tables makes understanding much more difficult.

As Elizabeth observed, Agile promotes choosing the best technique for the job. Sometimes, it might be User Stories (for simple flows), sometimes Use Cases (for complex flows), and sometimes both.
Reply | Reply with quote | Quote
+3 # Seo Keo 2014-03-05 03:15
In my practice, user stories pave a way for Use Cases as a project moves towards its execution phase. These are just tools to do the job. Their use depends on project nature, its milestones and delivery deadline. No strict rules, so use as you go, be agile and experiment with what is best for you.
Reply | Reply with quote | Quote
-1 # Shane Hastie 2014-03-05 07:56
I'm thrilled to see the feedback and comments to our article.
Of course teams can choose to use use use cases instead of user stories, or vice-versa. However we admonish "don't use both" and if you are going to use use cases then do them in the way that Use Case 2.0 recommends - iteratively and incrementally growing the detail,

All too often what we see is teams adopting agile and then reverting to BDUF behaviour because use cases are familiar and they don't make the thought transition to incremental development and just in time thinking. For those teams making a hard switch from use cases to user stories can help break the bad habits.

I also suggest that a use case may not be the best tool for expressing complex business rules or complicated interactions, neither will the structure work for those complexities - in my experience a simple visual model made up of lines and boxes (call it an Activity Diagram, Process Model or simply a flowchart if you want) will be a better tool for conveying complex interactions and scenarios than any text-based model.

Thanks everyone who commented for taking the time to read and respond.
Reply | Reply with quote | Quote
-1 # Angela Wick 2014-03-05 08:16
I echo Shane's thanks for the great comments and contributions to the dialog.

Yes, the title is provocative, and our underlying message intends to help demystify and call out a risky usage of the techniques within the agile approach, not to say that one is right or wrong.

In the hundreds of organizations I interact with in my consulting and teaching I am seeing too many organizations use the techniques in ways that are counter to what they are trying to accomplish. I am a fan of Use Cases 2.0, but have not seen wide adoption yet; I more commonly see "agile" teams fall into 100 page Use Cases with too much design and details, defeating the agile mindset and purpose of collaboration and feedback loops to get to the right design. All to often, agile project teams do rework to rewrite parts of Use Cases based on their learnings. This is a red flag that the usage of the Use Case technique is not aligned to the agile approach and too much detail is being done too early.

With User Stories I am seeing that many organizations are not fully embracing Acceptance Criteria as part of a User Story and are reverting to familiar Use Cases vs. using Acceptance Criteria appropriately. Acceptance Criteria can successfully outline and progressively elaborate the detail as needed. These teams then risk the agile approaches integrity by using Use Cases in a way that may not be efficient for agile teams and not fit for purpose.

There are teams using both with success, each team's needs are unique. We are hoping to bring a conversation to the table that helps teams evaluate their situation with more clarity.

Thanks for the continued dialog!
Reply | Reply with quote | Quote
+8 # Ross Little 2014-03-05 10:58
I understand and agree with the intent to simplify and eliminate duplication and confusion; however we have found a valued place for appropriately detailed use cases to provide context for user stories and to assist in both the discovery and validation of backlog items and acceptance criteria.

In many of our complex agile engagements, we have found significant value in modeling or referencing level 0/1, semi-formal, black-box business use cases (or business process models). I recognize they may not be right for every situation, but to say they are unnecessary in a world of story maps and acceptance criteria implies a very specific and limited interpretation of these methods.

I contend that the appropriate use of all of these together actually minimizes rather than adds risk. The key word is appropriate -- for I certainly agree it would be anti-agile if (inappropriatel y detailed) use cases were no more than detailed user stories. A use case that is a mere duplication of effort that provides no value beyond a well discussed, understood and complete set of epics, user stories and acceptance criteria is certainly not necessary. Though if stories can be discussed more easily with the awareness of process (and architecture – though that’s another topic,) go for it.

I think the main disconnect is the assumption that use cases imply detail. While they can, they don’t have to. And if used in conjunction with user stories, it is our recommendation and practice at IAG that the form of use case (its type, focus, style and detail) be governed by the supporting role it plays to communicate the context, and ensure the eventual completeness of the stories (and acceptance criteria.) The effective use of any complimentary technique should not put an agile approach at risk. Used appropriately, use cases can fill a beneficial role. Keep to your agile values and principles, but we say go ahead, use them both if it helps.
Reply | Reply with quote | Quote
0 # Kristopher Goins 2014-04-09 13:16
It was IAG that gave me a strong foundation in use case creation during a large mult-state consortium formally known as AWIN. I have found on more than occasion people trade complete and fully detailed for quick and easy. I see no harm in executing both as long as there is a traceability between the two.

Thanks Ross!
Reply | Reply with quote | Quote
+2 # Leslie 2014-03-05 15:27
The authors appear to be well-versed in user stories, but perhaps not so experienced with use cases.
I agree with the concept that one should probably not be doing the same thing twice, once with user stories and again with use cases, but then use cases provide so much more benefit to the product than user stories. In addition user stories can be used to compliment the benefit of use cases, without unnecessary duplication.
Consider that there are 2 major purposes for requirements. To describe the system that is to-be, and to describe the system as-is.
Use cases are great for capturing an as-is system and also great for capturing the to-be system. The problem is that they do not capture the difference between the 2 systems very well.
Here is where user stories come in to the picture. User stories are not intended to be persistent, (i.e. they do not describe the as-is system), because they are effectively discarded once done. They do however capture what is 'needed to be done' (the difference between as-is and to-be), very well.
Summary: If used as intended, use cases and user stories can compliment each other very well. In fact, if your project/program includes the BA role, the as-is picture is essential, and user stories are not going to provide the complete picture.
Reply | Reply with quote | Quote
0 # Mike 2014-03-05 17:27
Great article with very good explanations of user stories, epics, decomposition and acceptance criteria.
Isn't this article really making the case to not use use cases on Agile projects, no?
I think the reason agile teams ‘revert’ back to use cases in Agile projects is the sprint planning and fear that teams will over-commit and/or teams don’t know what they’re getting themselves into.
Oddly enough, I just read a different article on projecttimes.co m on 2014 trends in business analysis and project management which indicates ‘Use cases will enjoy a resurgence, particularly on Agile projects'.
Reply | Reply with quote | Quote
+2 # Waqas 2014-03-06 09:14
I would second Kent - "simplify and do only what makes sense and contributes to satisfying your stakeholders needs."

As a Business Analyst in Agile environment, I have successfully used a modified version of traditional User Story template to list all the relevant business rules under a User Story. This eliminates the need of Use Cases. However, for project that involved complex problems, I supplemented User Stories with System Workflows too.

Not truly agile but it works for us.
Reply | Reply with quote | Quote
+5 # Sharon Spragg 2014-03-06 18:57
use cases just wont die!! and there is a good reason for that.

The crucial point here is that teams are going back to use cases over and over again even though Agile says dont :-).. instead agile should try and accept that if a team thinks a use case is the just right documentation for the project then that is a very agile concept. As is doing the use cases at the right time in the project - just prior to the development.

my experience of both stories and use cases is that use cases provide structure to BA's in their thinking, so they feel "safer" to use. the most common issue with fleshing out a story is, have we thought of everything at the right time.

in my current Org, we use the story format to define the high level business needs as it makes our business think about who wants it, what they want and why . it also provides a good consistent structure and ties in with the context diagrams that describe the problem space.

we then swap to use cases supported by screen mockups to flesh out what they really want the system to do for them.

use cases are good at identifying complex system interactions due to their structured nature.

we have already taken care of the "why" by identifying this in the user stories that precedes the use case. so we are clear on why we are doing this development, and the use case helps us understand the complex system interactions that need to be built.

plenty of room for lots of different techniques in the Analysis Space, particularly when working in an Agile environment.

so lets forget prescriptive Agile and instead identify for our specific project, the best method of documenting what is needed taking the needs, objectives and constraints of the project into account .. and if that's "shall" statements, or use cases, or stories or whatever, then that is as Agile as can be.
Reply | Reply with quote | Quote
0 # Ryan Rigby 2014-03-07 11:51
A well written article, in principle I agree with the arguments made. I second Jenny's comments that Use Case have evolved, particularly in stating the WHY
Reply | Reply with quote | Quote
0 # kupe 2014-03-07 15:05
I have not read all the comments in detail so I apologize if I repeated something. I would like to see Shane and Angela reply to Sharon's comment above.

After reading the post, it appears the argument is more for not doing all the Use Case detail up front. I agree with that. But is it an epic fail and not agile to use them as Sharon and her team are using them?

I say do what works. Yes there are things that don't make sense and teams need to stop doing things just because they are part of a process. If a technique is comfortable for a team and the team is effective in delivering value, is it wrong?
Reply | Reply with quote | Quote
+1 # Angela Wick 2014-03-09 12:52
In response to Kupe and Sharon: I agree with much of what both are saying. What I question is the approach of using Use Cases to detail out requirements before development. This is counter to the Agile mindset. Sounds more iterative than Agile.

I also keep hearing comments refer to complex interactions being the need for Use Cases . . . putting complex interactions into Use Cases prior to development hampers innovation and compromises the agile approach.

Detailing out before development I think this is counter to an agile mindset . . . I am sure there are successes of this approach, I question if these successes can be even better by following a truly agile approach?

Where I see teams having success is peeling back the complexity layer by layer by evolving acceptance criteria through progressive elaboration, having dialog, developers develop a layer, and then more feedback, dialog, and another layer of acceptance criteria and complexity evolves. There are many structured ways to organize and write up acceptance criteria; the trap is not knowing these structured ways and reverting to the comfort of Use Cases and hence the trap of big detail before giving it to a developer.

This complexity being discussed as the driver for Use Cases is often driven by business rules complexity. Use Cases do not allow us to see these rule inconsistencies and question the value of the business rules in the bigger picture.

@Kupe - If a team is having success with Use Cases in Agile is it wrong?
No, and there still may be areas to improve and build software faster and cheaper with higher quality. It depends on the teams readiness for continuous improvement and a mindset of continuous learning and discovery.
Reply | Reply with quote | Quote
0 # Indian 2014-03-10 23:57
Shane & Angela, Wonderful & well thought out article. Thanks for sharing this.

I believe this confusion usually happens because Agile as a methodology of implementation is relatively new vice-vie the other methodology or I may say its adoption for execution is picking up but not at par with Old School SDLC techniques like Waterfall.

This is the very reason of confusion for the organizations who are planning to go Agile (User Stories) but still want to use the old school techniques (Use Cases). They’re trying to find a mid way between these approaches which leads to a mess.
Reply | Reply with quote | Quote
0 # Duane Banks 2014-03-26 10:00
It seems to me that the problem in this article is the notion that Agile is a methodology. If Agile is a methodology, then than the authors may vey well be right, the usage of both use cases and user stories is not Agile.

ButI don't see Agile as a methodology. The methodology is scrum, Kanban, DAD, etc.

If Agile is not a methodology, then what is it?

Many say it is a "way of thinking." I tend to agree.

That said, what does a "way of thinking", have to do with software development?

Don't you guys think it's time we remove "Agile" from the IT vocabulary?

Certainly, doing so would result in the reduction of a great many disagreements in the BA ranks.
Reply | Reply with quote | Quote
+1 # Tim Wright 2014-03-31 02:19
Hi,

While I agree that doing all your use cases first isn't really agile, I disagree that you can't use them at the same time as user stories. The two tools have quite a different focus. User stories are not really requirements documentation. They are a representation of some work that the team will do. A use case is a description of how a user achieves a goal - nothing more and nothing less. A use case can just be a paragraph of text - it doesn't need fancy "alternative flows".

Using them together, user stories let you answer the question "what is the most important piece of work the team should be focusing on right now". Use cases let you answer the question "have we delivered sufficient functionality for a user to achieve a goal". I find that storyboards do not provide sufficient structure to answer that question in a meaningful way. Use cases do.

As a disclaimer, I'm slightly biased. I've taken Alistair Cockburn's course "Use Cases to User Stories". He talked about several different ways to use the two things together - a very interesting course given he wrote the book on use cases and also is one of the signatures on the manifesto :)
Reply | Reply with quote | Quote
0 # Etienne 2014-04-09 15:41
User Story defines what is required and the Use case (and supporting artefacts i.e. UI designs, sequence diagrams etc.) defines the how. Both are valid but at different level of detail at different stages of the SDLC. Identified use cases and associated user stories early on in order to estimate the effort and budget required for the project (mile wide inch deep). User stories associated to identified use cases is a reminder of who requested what and with what acceptance criteria. Full designed use cases follow from this (inch wide and mile deep).
You now have the following associations:
Process has o..n use case,
Use case has 1..n user story,
User story has 1..n test case
Reply | Reply with quote | Quote
0 # Shane Hastie 2014-04-10 03:03
I have no problem with use case thinking, and doing informal scenarios (Cockburn’s lightweight use cases) often makes good sense when done as part of the elicitation workshop process, however what we have seen happening out there (which prompted us to write the article) is organisations tasking business analysts to go out into the business, conduct interviews, write detailed use cases (defining every path and alternate flow) independent from the rest of the team and then copy-paste the flow steps into user stories – this is just big requirements up front disguised at agile and is a very dangerous practice.

I do feel that a story map (a-la-Jeff Patton) will provide a better view of the end-to-end process and provide all the value that a set of use cases could deliver, but in a more adaptive manner.
Reply | Reply with quote | Quote
0 # Tim Wright 2014-04-11 17:23
Hi Shane,

That is not a problem with use cases. That's a problem with organisations thinking they still need a "detailed requirements phase". Your argument applies equally to process models, data flow diagrams, petri nets, requirements lists, and even user stories themselves as some organisations might want a full detailed list of user stories before starting development.

On that, I dare you to write an article called "don't use user stories and user stories on the same project".
Reply | Reply with quote | Quote
0 # Etienne 2014-05-27 22:30
I believe when you follow TOGAF principles, then you first have a mile wide inch deep comprehensive view of the problem before moving to phase G: Implementation Governance where either waterfall, agile, iterative SDLC approaches could be used. User stories (what) can be assigned to sub-processes (business use cases) in phase B: Business Architecture. This is then elaborated to system use cases in phase C: where technical actors are assigned in order to estimate the overall project early in the life cycle using use case point calculations. In phase F: Migration Planning you now can prioritize the backlog by use case priority. Now in phase G: you expand the prioritized use case into scenarios, adding UI designs etc. This is done under control of the associated user stories (what). The scenario steps indicate the functional requirements (fine grain user stories) and when using a modeling tool can be associated with UI designs, input / output data, business rules etc.
Reply | Reply with quote | Quote
+2 # Alan OCallaghan 2014-06-24 06:53
What a great discussion!
However, there is a fundamental premise in the original article that I disagree with: that user stories and use cases address the same space. They don't. Stories describe a user need as a starting point for conversations about the system requirements that meet that need. They are not systems requirements themselves. Use cases on the other hand, do describe system requirements, that is exactly why are they are so detailed. They are therefore a viable choice (not the only one by any means!) for a development team that feels there is value in documenting the outcome of the conversations driven by the user stories. Many highly mature teams derive their tests from the use case description of the system requirements (BTW, the examples given for 'acceptance criteria' were actually detailed acceptance test cases: you can normally only get to those by drilling down in some way to system requirements from the high-level acceptance criteria written on the back of user stories). Story mapping is a great way of decomposing epics to finer-grain stories and helping teams determine Release and Sprint goals in terms of user need and user value, but they don't get you to the detailed system requirements - unless you want to venture into the 'story card hell' of having all your requirements distributed between hundreds of cards.

So, bottom line: I totally agree with the authors that substituting use cases for user stories is BUFD and is not a good idea. But the notion that you cannot combine stories together with use cases is disproved by the hundreds of successful Agile teams doing exactly that right now
Reply | Reply with quote | Quote
0 # Steve Orr 2014-07-03 11:03
The original article in this conversation referred to business rules. Business rules belong to the business and not to any one single project. If they are managed and maintained by the business, they can simply be cross referred to from a scenario.
Reply | Reply with quote | Quote
0 # _theone 2014-08-28 10:20
You're still using Use Cases with your User Stories despite calling them Acceptance Criteria.
Reply | Reply with quote | Quote

Add comment


Security code
Refresh