Can one use use cases on a agile project? do use cases provide any value for agile teams?
I' m going to put out my opinion unequivocally Yes, Yes and Yes.
Most agile purists would disagree with me on all the three above points. Typically agile development approaches use user stories, backlog items, or other simpler mechanisms to describe requirements. They often have the format of "as a student i can purchase books". These requirements are typically put on an index card, and then not elaborated until it's time to code, and usually only by conversation, sometimes with a couple lines of text.
First of all let me state that I find user stories very useful for estimating , planning and tracking. I don't however find them very useful for providing context, structure, or abstraction. My experience has been that using user stories alone does not scale very well when working on large projects where multiple views of requirements are needed. For instance, a high-level view for project directors and other executives or a more detailed view for developers.
I can appreciate the bias that most agile practitioners have against use cases, because frankly, most use cases that I have come across in my experience are very poorly done. They are hard to read, they have way too much structure, rely way too much on UML syntax (extensions and usage relationships) and can often digress into what I call "functional decomposition". In order for use cases to provide value to any Project, agile or not, they need to be written properly. I specifically recommend two excellent books, Patterns for Effective Use Cases and Writing Effective Use Cases both of which Alastair Cockburn either authored or co-authored.
What I have euphemistically coined the "Cockburn Use Case Approach" describes how to write use cases with just enough formality and structure to allow proper abstracting, good context, multiple views, etc.; while still being readable by end-users, and not requiring a massive amount of effort to build and maintain. Most importantly, this technique focuses on writing scenarios using natural text, not on creating uber complex UML diagrams.
Alistair Cockburn has posted a pretty good piece justifying his use of use cases which I recommend taking a look at.
Some other comments on the topic can also be found here
A Brief Case Study
I have decided to share a brief case study regarding the own experience with user stories and use cases in general.
About five years ago I was asked to take a fairly large public sector program that was being previously conducted in a waterfall fashion and focus on getting some very quick functionality out the door. The client was previously frustrated by the millions of dollars spent with only paper documentation (and not very good documentation at that) to show for it. I lead a small task force of around five developers for about six months, our goal was to try to win back client confidence by delivering "something" quickly, and iteratively. We followed the XP process as it existed at the time, using user stories, velocity, etc.
While overall it was very successful, we quickly ran into many of the problems stated above. We had a lot of problems organizing our stories into a higher context, and we had no executive view which would allow client leadership to let us know if we were generally in the right direction. As a result, we wasted a lot of time developing functionality that was never actually used. (Often users on the ground working with agile teams do not have proper executive context, just a fact of life at least in all of my experiences)
As the program started to grow in size with multiple teams, I started looking into use cases, going through a variety of use case books until I came upon Writing Effective Use Cases and Patterns for Effective Use Cases. We started writing use cases according to the advice in these books, and saw great value immediately.
In all other respects, we still followed an iterative process, we developed use case briefs for a large portion of the use cases upfront. These then acted as our user stories in terms of planning, and estimating. The first thing we then did at the beginning of each iteration was to develop scenarios and extensions for use cases assigned to the iteration. Still agile, still iterative, but we used use cases.
Why Aren't These Cases Accepted within the Agile Community?
Throughout the last five years I have subsequently been a lead architect and process lead on no less than five separate projects (some very large and some very small) where I have used these techniques for use cases. I combined these use cases with other agile approaches (CRC, story points, test driven development, etc.) and have found them to be fantastically useful. This whole agile bias against use cases stems from the fact that use cases are probably one of the most abused SDLC related artifact. There are many different ways to do use cases, and from what I've read, most of them are just "wrong". But when done according to the advice found in these two books, they can really support an agile approach. I'm also confused by the agile maxim that you should "do what works", as long as you don't use use cases, never do any upfront modeling, don't use any case tools, etc., etc.
IMHO this sometimes religious bias against other tools can sometimes limit the appeal of agile by nonbelievers. I'm probably going little off-topic and will stop there.
Maybe the whole agile bias against use cases is a reaction against previous BUFD. But I still agree a little bit of upfront thinking is always going to benefit any development effort, as long as the emphasis is not on creating a requirements document, but doing the necessary thinking required to ensure that the right product is developed.
I think use cases can easily mapped to user stories, and can fit into almost any agile process
summary use cases > epics, themes
system use case > regular user stories
use case briefs >user story descriptions
use case details >part of iteration planning, determining the iteration objectives.
I will continue to use use cases on future projects, but combining them with more traditional agile techniques.
Jeff - I'm interested in this subject currently as I find myself working on a very large integration project that is stalling at the first hurdle because no-one can agree on how to document the work. There is a Business Requirements document and some idea about generating user stories from it. However I just recieved an integration guide for some prototype stubs and I asked if I could see the relevant user storties only to find that they didn't exist. So there is no context for the integration guide - lots of stubs - but what are they for?
ReplyDeleteThis is a different context problem to the one you mention though - I have a couple of questions...
1. As the Devils Advocate - Would themes give you the context you are looking for in relation to user stories - so there is a hierarchy of user stories in effect - the highest one could be as a Sponsor I need a website that sells books so I can run my online business - and each branch diggs deeper.
2. Do you think there is any value/waste in having usecases and deriving user stories from them - some sort of traceability mapping between them? Seems a bit pointless to me - could you see any advantage in that?
Dave ,
ReplyDeleteI believe themes would be useful for applying context to lower-level user stories.
I also agree with you that creating full-blown use cases and then mapping them into user stories just so you can have a little bit of context is probably overkill.
However, portions of the use case approach can still be helpful when using user stories.
Something that I find myself doing frequently these days is creating a use case hierarchy plus briefs that provide a paragraph description of all the use cases in the system (these description could be thought of as being equivalent to user stories or themes) as well as organizing the use cases into a parent-child hierarchy.
This has some added flexibility compared to the theme>user story hierarchy as it supports multiple levels within the hierarchy creating as much context, or as much detail as you need.
If I'm going to use user stories, then these would be the only parts of the use case that I create, no alternate scenarios, exceptional flows, et cetera. Just a paragraph of text, the use case parent, and potentially a set of use case "children". I think this approach to use cases is fairly conformant to the agile view of very light documentation.
Sometimes I will need more structured requirements, and I might break out my use cases into separate scenarios. I still have the choice of following a more typical structured use case approach, or again, I can be more informal using plain text. These scenarios could map directly to a user story without needing to do any additional work.
In order to determine if use cases have any value on your project over typical user stories I suggest taking a look at http://www.amazon.com/Writing-Effective-Cases-Software-Development/dp/0201702258 , it's probably the most useful use case book I've ever read. See which parts of a use case can actually be used in your situation.
You might find having your user stories extended with typical use case components such as primary actors, exception conditions, and business rules to be incredibly useful, then again you might not find it useful at all. I probably never written requirements exactly the same way twice on two projects, always ranging between a typical informal user story, and a fully dressed well structured use case. I've always looked at it as more of a range of formality rather than an either or situation.
Hope that helps
Jeff
Thanks
ReplyDelete- I'll look up the book as I want to know more - there seems to be some bridge between agile and traditional methods here - also I'm wondering what is the difference really if User Stories are combined with Satisfaction Criteria and given Persona Contexts they probably turn out just as detailed as Use Cases - certainly the way you seem to be using them.
Hi Jeff,
ReplyDeleteI've often used use cases in the most informal way, trying to follow Cockburn's view rather than the established RUP templates.
In general, what I've found disturbing about templates is that often people just "fill the blanks" without providing the key information. But maybe this happens only depending on the people regardless of the form used to capture requirements.
I've recently tried to explore the stories approach and found that the diversity is basically on the time placement of the analysis operation. As Cohn said, a story is a placeholder for future conversation. This is fine, cause the problem NOW can be different from the problem 2 month ago, and 99% of the time the better version is the latest.
But when facing the conversation, you got to ask basically the same questions that are outlined in a Use Case template. In other words, you can't effectively adopt User Stories if you don't know use cases well.
But time replacement has also some risks associated.
In some cases, the domain could be very complex. I've had colleagues spending weeks trying to analyze a single use case, working it out with the domain expert. In such cases, a story approach would have probably halted the development process: more people would have been involved in a pretty longer "conversation" with a high risk of becoming endless without the specific knowledge distillation contribution that the analyst could provide. This can be more problematic if domain experts are not so consistent in providing answers.
best regards
Alberto
Alberto,
ReplyDeletethanks for leaving feedback!
I absolutely agree with you that one of the biggest issues with use cases is that people fellow a "fill in the blank approach", I often have use case templates with lots of sections, but if I don't use a certain section for a certain use case I will remove it so as not to clutter what I have filled in.
I also like the ability of structuring my conversation into main and alternate scenarios, exceptions, plus other adornments etc. I find user stories just don't tell me enough...
you're right in saying that there is a risk in building detailed use cases, mainly that the details of a use case can change quickly over time, and usually the latter version is the better one. I try to mitigate this by only developing use case briefs in advance of development. I then detail out other use case sections during actual development iterations, using a just-in-time approach as a direct precursor to development work.
Jeff,
ReplyDeleteI recently came across your blog as I was looking for how others feel about using User Stories for capturing requirements. I am consulting on a large government project where our product owners are of similar opinion as you. Although I understand where you guys are coming from, I would argue, not as an Agile purist though...:-), that the reasons you cited for using Use cases can be addressed with just User Stories. I talk about this here- http://blog.syedrayhan.com/.
I would be interested to hear what you think about my suggestions.
Syed
syed,
ReplyDeleteMy personal preference is to use use cases rather than user stories because I find I have some flexibility to inject a little bit more structure if the situation warrants it. I find user stories to be just a little bit too brief, user stories also only seem to support a hierarchy of two levels, epics>user stories, on the other hand use cases have sub functional, system, and summary of multiple levels. I can make a nested hierarchy that supports whatever level of detail I need.
That being said, lately I've tended to only do use case briefs and hierarchy, and skip the scenarios and other sections altogether. This, in all respects is very similar to a user story.
However, at the very least I will have a paragraph or 2 describing the purpose of the use case, as well as any important considerations. I would then supplement more detail using techniques described by Eric Evans in the excellent book Domain Driven Design.
Example:
user story >as a student,I can purchase books
Use case >Purchase Books, primary actor >Student
More important than whether you use these cases or user stories, is the ethics and principles behind the creation of each. I.e. travel light, build your documents with a specific reader in mind, and keep any documentation as "close" to your code as possible.
Jeff
I agree with Jeff on the use of use cases to document functional/behavioural requirements. Bottomline is that no matter what template format etc you follow, if one is not documenting the right substance and at the right level of detail, it all becomes a wasted effort. I personally have found that use cases do tend to bring in the discipline to not only capture the story but also capture other critical information (using pre-conditions, triggers, actors etc.) which is essential for modeling the system correctly. I personally don’t paint my usecases with UML (I have seen many instances of that on various projects) and I have found that business users/developers like it that way… keeping it more descriptive and capturing the key information should be the primary focus of a use case. Having a clear mapping of use cases (sea-level usecases) to the To Be process flows is critical and using use case heirarchy/summaries to achieve that is completely acceptable and infact recommended in some way, shape or form. In my view, people should not write orphan use cases and every use case should belong/map to the "To Be" world.
ReplyDeleteI haven't yet embraced any school of methodolgy as I strongly believe that every situation is different which is proven by the fact that there are so many successful methodologies out there. The BigM methodology seems to make more and more sense to me as I delve deeper into it. It's basic premise that "one size doesn't fit all" resonates with my personal thinking around methodologies… I have yet to use a methodology in it's purest form on a project… it has always been a hybrid methodolgy that is eventually used. Use cases on the other hand, I believe, should be methodology agnostic as they help better execute on whichever methodology one chooses to use.
Hi,
ReplyDeleteI don't see the Use Case / User Story debate as an exclusive one or the other.
We can write Use Cases to several levels. The highest level might migrate directly to User Stories,or not, depending on what you see as needing to be fleshed out.
There are good reasons for having a high-level architectural view. The issue is how much detail needs to be provided up front. It's a judgement, not a fight.
So, I would probably use high-level Use Cases to map out the scope of what I am building. Some of these will turn into elaborated or fully developed Use Cases, depending on the level of analysis/risk associated. If they need a lot of customer dialog for clarification then I do that, if not , not. It's a choice. Breaking the Use Cases, developed or otherwise, into User Stories, is a good technique for focus, progress monitoring, and many other reasons besides, the main one being the opportunity for frequent feedback (from user / tests), which is always to be encouraged.
Personally, unless the task is to make a series of disjointed changes to an existing system, I have trouble in seeing how a similarly disjointed set of User Stories can deliver an integrated system. On the basis that there is some truth in "the whole is more than the sum of the parts", I still use Use Cases to provide my high-level road-map.
gCambridge
ReplyDeleteyou're right on the money that it is not an exclusive. I frequently use both, especially since in my opinion, an agile release plan is table stakes for any serious development effort. This requires breaking up use cases into user stories, which can fit into a specific iteration.
I find use cases great for getting my overall structure of the system, but you need to break these things into tangible units of work that can be estimated and tracked. This is where user stories command.
Jeff
Maybe i'm missing something, wouldn't it be more logical to start with user stories and then add a little more detail/context with use case briefs or informal use cases? For example:
ReplyDeleteUser story: as a student i can purchase books
Use case brief: The student need to purchase a book. The student accesses the online store and selects the book. The student enters the payment details and confirms the purchase..
Something like that. I say this, because i've been reading http://tynerblain.com/blog and there's an entry there that seems to support this approach:
http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/
Ok, forget the previous post (it was me :)
ReplyDeleteI get it now.
You can derive user stories from the use cases, not the other way around.