Business Analysis Thought Leadership - Articles



BA ARTICLE ARCHIVE
» July 2014 (5)
» June 2014 (7)
» May 2014 (5)
» April 2014 (5)
» March 2014 (7)
» February 2014 (6)
» January 2014 (6)
» December 2013 (7)
» November 2013 (4)
» October 2013 (5)
» September 2013 (6)
» August 2013 (8)
» July 2013 (8)
» June 2013 (7)
» May 2013 (8)
» April 2013 (8)
» March 2013 (4)
» February 2013 (6)
» January 2013 (6)
» December 2012 (5)
» November 2012 (7)
» October 2012 (6)
» September 2012 (6)
» August 2012 (5)
» July 2012 (9)
» June 2012 (5)
» May 2012 (9)
» April 2012 (7)
» March 2012 (7)
» February 2012 (5)
» January 2012 (7)
» December 2011 (6)
» November 2011 (6)
» October 2011 (8)
» September 2011 (6)
» August 2011 (8)
» July 2011 (7)
» June 2011 (7)
» May 2011 (5)
» April 2011 (8)
» March 2011 (6)
» February 2011 (5)
» January 2011 (6)
» December 2010 (5)
» November 2010 (9)
» October 2010 (5)
» September 2010 (6)
» August 2010 (8)
» July 2010 (6)
» June 2010 (6)
» May 2010 (10)
» April 2010 (5)
» March 2010 (8)
» February 2010 (7)
» January 2010 (7)
» December 2009 (7)
» November 2009 (7)
» October 2009 (6)
» September 2009 (8)
» August 2009 (10)
» July 2009 (9)
» June 2009 (5)
» May 2009 (10)
» April 2009 (5)
» March 2009 (12)
» February 2009 (8)
» January 2009 (6)
» December 2008 (9)
» November 2008 (8)
» October 2008 (9)
» September 2008 (4)
» August 2008 (6)
» July 2008 (8)
» June 2008 (17)
» May 2008 (12)
» April 2008 (7)
» March 2008 (21)
» February 2008 (16)
» January 2008 (13)
» December 2007 (9)
» November 2007 (25)
» October 2007 (2)
» September 2007 (23)
» August 2007 (12)
» July 2007 (11)
» June 2007 (7)
» May 2007 (6)
» April 2007 (9)
» March 2007 (5)
» February 2007 (3)
» January 2007 (2)
Articles and White Papers
Thursday, February 28, 2013
10617 Views 11 Comments 31 members voted Article Rating

Has “Agile” killed “Use Cases”? Let us answer this question in this short article.

As you may know, “Use Cases” have been a great way to document the detailed “Functional Requirements” of a system. Books—such as Writing Effective Use Cases by Alistair Cockburn—do a great job of explaining how to write detailed use cases.

Sponsored by:

Accompa

As you also know, “Agile” has been the rage among software development teams for the past decade or so. Agile development processes such as Scrum and X Precommend as little documentation as practically possible.

Most of the Agile processes recommend that requirements be documented on index cards or sticky notes (i.e. just a line or two) in the form of very short “User Stories.”

Does this mean “Use Cases”, the long-form way to document functional requirements, are now dying or even dead? Has Agile killed the use cases?

Agile vs. Documentation

As explained at the Agile Manifesto website, “Agile” is about “better ways of developing software.”

Agile manifesto includes 4 items:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

Many Agile software development teams interpret point #2 above to mean something along the lines of “detailed documentation is the enemy of Agile.”

I find this interpretation incorrect—and perhaps a little self-serving too, as it is easier to deliver when there are no detailed requirements to deliver against!

What are User Stories?

Agile processes recommend requirements be documented on index cards or sticky notes (i.e. just a line or two) in the form of “User Stories.”

A “User Story” is a very short description of a feature written from the perspective of a user. User stories are the key requirements artifacts in Agile projects, and typically follow a simple 1-sentenceformat such as:

As a [type of user], I want [some feature] so that [some benefit].

Here is a practical example of a user story for a CRM system.

As a sales manager, I want a weekly pipeline report so that I can track the performance of my salespeople against their quota.

User stories are typically written on index cards or sticky notes, and then arranged on walls to facilitate discussion.

Pros and Cons of User Stories

Pros:

• Short

• Easy to read and understand

• Modular & easy to rearrange

• Emphasizes working software over documentation

• Efficient way for small, collocated teams to build software

Cons:

  • As user stories are very short, it is hard to document detailed functional requirements

  • Best used as pointers to detailed requirements

  • If used to replace detailed requirements, they usually do not scale for large-scale or complex projects

What are Use Cases?

I’m using “Use Cases” in this article to refer to the text-based functional requirements used to document the story of an actor interacting with the system under design (SUD) while achieving or failing to achieve a goal.

Please note I’m not using “Use Cases” here to refer to UML diagrams, or other graphical documentation.  My views about using text to document use cases (as opposed to diagrams) are in line with the views expressed by Alistair Cockburn in his aforementioned book, Writing Effective Use Cases.

Here is a practical (and simplified) example of a use case for a CRM system.

  1. Sales Manager selects “Weekly Pipeline Report” from the menu.

  2. System displays “Run Weekly Pipeline Report” screen.

  3. Sales Manager selects desired week and territory—and runs report.

  4. System generates the “Weekly Pipeline Report,” and provides options for Sales Manager to download the report in Excel, PDF, or Word formats.

  5. Sales Manager downloads the report.

Pros and Cons of Use Cases

Pros:

  • Great way to document detailed functional requirements

  • Text-based use cases are easy to read &understand

  • Scale well for complex projects involving globally distributed teams

  • Easy to create relationships to tie use cases together. See the free eBook, The Practical Guide to Use Cases, for details

Cons:

  • Not as short as user stories

  • Easy to go overboard and start emphasizing documentation over working software

  • Using UML or other graphical ways to document use cases will make them hard to read and understand

So, Are Use Cases Dead?

While user stories work great for Agile software development teams, it is very hard to document detailed functional requirements using just user stories.

I believe user stories are best used as pointers to detailed requirements—rather than as replacements for detailed requirements. Use cases, on the other hand, are a great way for us to document detailed functional requirements.

This brings us to the answer to the titular question:

No, use cases are *not*dead!

In fact, when properly utilized, use cases offer the most efficient and clear way to document detailed functional requirements. They can save your team valuable time, while ensuring the delivered software meets the needs of users.

Refer to the free eBook, The Practical Guide to Use Cases, or Alistair Cockburn’s Writing Effective Use Cases book referred above for further details on how to write and utilize use cases for your projects.

Author: Michael Shrivathsan has requirements management experience spanning two decades at successful software companies in Silicon Valley, USA. He is the VP of Product Management at Accompa, the company behind the popular requirements management software used by Business Analysis, Product Management, and related teams.

References:

  1. The Practical Guide to Use Cases–FREE eBook that gives a practical introduction to use cases.

  2. Writing Effective Use Cases – an excellent book by Alistair Cockburn on writing use cases.

  3. Free Trial of Accompa – cloud-based software to manage use cases and requirements.

  4. Requirements Management Software by Accompa – website where you can find out more information about Accompa cloud-based software

Posted in: Agile Methods
Rate this:

COMMENTS

Posted on Tuesday, March 05, 2013 4:01 AM by
Datalover
Good article! I think agile can not replace use cases, especially for business analysts, take database computing for example, users mainly use SQL, R and esProc script to deal with complex data computing, while some more easier tools like Excel, esCalc and many other Excel addins have make the complex data process much easier or more agile, but the use cases always exist, as the problems are also the same, just the tools and methods are different.
Datalover
Posted on Sunday, March 10, 2013 8:30 PM by
saubi81
A user story template also has "Acceptance Criteria", "Given", "When" and "Then". This means that a user story's structure is essentially like a use case. A use case's structure is:

Use Case Description
Actors
Assumptions
Triggers / Pre-conditions (I plug in trigger with a pre-condition)
Primary Workflow
Post Condition
Business Rules

Equivalent template in a user story will look like. A user story doesnt have any workflow:
User story Description (This compensates for Actor and Use Case Description)
Given
When
Then
Acceptance Criteria


If someone is looking forward to create a comprehensive documentation then user stories arent as good as use cases as they do not have workflow.
saubi81
Posted on Monday, March 11, 2013 12:22 PM by
vic23tor
Thanks for the review! I'm glad to see that I'm not the only man who still thinks that use cases is a useful tool. However, I wouldn't tell that UML makes use cases less clear. In my opinion, the graphical representation of use cases should go to pros, not cons: a textual version of a use case could be more confusing.
vic23tor
Posted on Tuesday, March 12, 2013 11:51 PM by
eddieosh
You missed out some key points regarding Agile and User Stories. The manifesto includes the important line "That is, while there is value in the items on the right, we value the items on the left more", i.e. comprehensive documentation is still valued, it is just that working software is where the true value lies -- documentation is a means to an end, whereas working software is the actual end and ultimate confirmation that the requirements have been satisfied.

A User Story is not equivalent to a Use Case as they each serve a different purpose; a User Story is considered to be a 'conversation starter' between the users and the development team, the expectation is that it will be elaborated and expanded over time as the team turns it into working software.

In the Agile Scrum approach, User Stories (the 'What') are converted by the team during Sprint Planning into tasks (the 'How') which are then implemented during the Sprint, the team all the time working closely with the Product Owner to understand and validate the business requirements. If the team wishes to capture these tasks as Use Cases that is up to them, they select what is best given the context, needs and their skills; however, in the majority of situations spending a lot of time on producing Use Cases is likely to distract the team from delivering value to the customer.

Agile development is focused around the team, not the individual, so the team works together to convert User Stories into software that is considered to be 'potentially shippable'; an analyst would not write extensive Use Cases to represent the business requirements and then throw these 'over the wall' to the team to treat as detailed specifications to be implemented -- that would be a sequential lifecycle that is the antithesis of the Agile approach.
eddieosh
Posted on Wednesday, March 13, 2013 8:31 AM by
Jonas
Both ways belongs to the past and should be buried with their practitioners. A new era of documentation has arisen during the last decade. IT need to take the back seat and subordinate to the fact that they are not the center of the universe. This is a normal consequence of all the failures from IT during the history of software developement. IT organizations not steping back from IT-driven methodologies will take impact from the natural selection and dissapear to be found by future archeologiest as the Dodos of an ancient time.
Jonas
Posted on Wednesday, March 13, 2013 3:55 PM by
JoelCran4d
Actually, User Stories are not requirements. Rather, they set the stage for requirements discovery.

In Agile, a user story is a formulaic expression (as Michael demonstrated) by a type of stakeholder or user of a specific capability or option in order to have a desired outcome or result. In other words, they state the business need for a feature or option, tying it to whom it is important.

User Stories are usually then broken down into Conditions of Acceptence ("COAs"). Not to be confused with 'acceptance criteria,' one or more COAs break down the user story into statements of verifiable functionality.

Example User Story:
As a frequent flyer, I want to enter my credit card number on the airline website so that I can quickly view my air miles balance without having to log in.

Example COA:
Given an unauthenticated frequent flyer user,
When they enter their credit card number
And when the credit card number corresponds to a frequent flyer customer,
Then their air miles balance will be displayed.

The COA is basically a 'mini use case,' and COAs are a vital part of user stories. They also guide the QAs in drafting testing scenarios (plus, our developers also use behavior-driven development; by prefacing the COA with a simple "Should see air miles balance:", they are able to include the COA as part of the unit tests in the code. Bonus!).

A good resource is "Discover To Deliver", a new book by Ellen Gottesdiener and Mary Gorman. They discuss the role of the agile project team in fleshing our requirements.

That said, agile calls for 'just enough' documentation. If the team works well with use cases, then by all means, use them. (I happen to like them, but I don't force them into a user story if they're not needed.) Use Use Cases, use UML, use snapshots of white boards. Use what the whole team needs, and wrap it up at the end in a post-deployment spec for future reference. Give just enough, stay a sprint or two or three ahead, but not too far as requirements can and will change.
JoelCran4d
Posted on Thursday, March 14, 2013 9:24 AM by
dwwright99
After a long period of trying to grapple with "agile" or "not agile" etc., I finally realized something --> it really depends on what you are trying to develop. My thoughts now divide software grossly between "product" and "process".

If you are developing a software product, especially to actually sell to customers, then I think product development methods are the way to go, and Agile fits this approach well. You do start with a Product Owner's vision of functionality, and user stories are a great way to express that vision as a starting point for developing a prototype or first release.

If you are dealing with a business process to automate, then a 'vision' is not appropriate; you have to document what the process is, completely and clearly. High-level process maps supported by use cases are a great approach for this. You have to realize that there can be no arbitrary first release for a process based on a sprint or other cut-off. If you are automating a process to, say, transfer money from one bank account to another, you can't first release the "from" account piece without the "to" account piece.

So, use the appropriate technique for the software you are developing; no one technique meets all needs.
dwwright99
Posted on Thursday, March 14, 2013 2:35 PM by
siranjeevi
good article..
siranjeevi
Posted on Tuesday, March 26, 2013 6:21 AM by
amol gade
nice article and all the contributors have nicely put their comments too!!!
amol gade
Posted on Wednesday, January 01, 2014 9:17 AM by
putchavn
Story in general and according to http://dictionary.reference.com/browse/story?s=t
is a narration of a chain of events.

As many things in "agile" to call a single sentence as a story is odd.
At best it is a "bead" in a "necklace" of a story.

UseCase a dialog between the SuD and a specific Actor to reach the UseCase Goal.
putchavn
Posted on Wednesday, January 01, 2014 9:27 AM by
putchavn
Sorry it got posted by mistake

So, what is called "user story" in Agile is an action step (with three components) by the Actor which forms a UseCase. A "user story" is a small unit which in isolation does not convey much. A set of such units is necessary to describe any functionality --- for which UseCase is well suited.

Why I call UseCase a DIALOG is explained in

http://www.slideshare.net/putchavn/usecase-case-is-a-dialog-not-a-process

Cheers
putchavn
Only registered users may post comments.

Do you twitter?: If you want short updates on what's going on in the BA world and at ModernAnalyst.com, simply follow us on Twitter: http://twitter.com/ModernAnalyst



Featured Digital Library Resources 

Copyright 2006-2014 by Modern Analyst Media LLC