We’ve spent many years enhancing our up-front functional documentation process—created in the form of use cases—to solve specific problems, all traceable back to one simple statement, “I need more information to implement this.”
Frighteningly, sometimes it wasn’t until we shipped that we realized the developers needed more information. We’ve now enhanced our process so that most of the work is done up front. The result? We have more accurate time estimates. Programmers are happy, there are fewer bugs discovered interally, and most important there are MUCH fewer bugs discovered once the product ships.
We have adopted many of the concepts of Agile development—such as daily build and test, build the smallest piece of functionality that delivers value, etc.—but have retained our up-front work. It’s worked extremely well.
-by Dave on 9/15/2009 at 10:35 AM
I never thought I’d contemplate user stories as being anything other than a flash in the pan. I couldn’t agree with you more Alistair about what you say in this article. But stories have ‘traction’ (ugly expression – sounds like snow tires). I’ve been looking hard at stories now and I think I like the fact that the users can get involved. That’s good. Not everybody makes a great story teller. Face it, when you get stuck next to a guy on a transatlantic flight and he tells you his life story in 22 minutes… ho hum). But people have a voice and they want to be listened to. Fine. But a decent story has a beginning, middle and an end. I can take this whole story metaphor a long way. In fact that’s what I did at http://masterstoryteller.co.uk/ . I reckon the Agile business analyst is really the story teller. Actually, I think I prefer that as a job title :-)
-by Peter Merrick on 6/2/2010 at 9:56 AM
Nice job title! sold!
I set in your URL ,and thanks.
Back UCs – how does the master storyteller keep all the upcoming details straight in her/his head? That’s where I’d consider inject UCs.
cheers – Alistair
-by Alistair on 6/2/2010 at 1:49 PM
UC and “Stories” are part of the SysML process for aerospace and defense systems and most importantly Systems of Systems (SoS).
Alistair may not have intended this when UCs moved into the agile domain, but for the multi-billion programs we work SysML and the associated UCs are a critical success factor.
-by Glen B. Alleman on 6/5/2010 at 12:25 PM
Hi, Glen — Nice you see you managed to get a post to stick (finally)!
I’m really glad to see UCs sticking somewhere. Super valuable technique.
Anyone using them for SysOps manuals or the like? A systems engineering predicted this to me in the 90s; wondering if it ever grew roots there.
-by Alistair on 6/5/2010 at 7:09 PM
I started out using use cases and I think its often their misapplication that forces people to move away from them (over specification of trivial scenarios that are low risk?). I have found user stories for more collaborative and easier to work with however, could you respond to a few points so I can play devils advocate :-)
“2.The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.”
User stories provide this with acceptance criteria being specified with users (from the story conversation), and context can be provided to a necessary extent for agile teams in the user story summary using the user statement e.g. “As a user who has saved a shopping cart I can … ” and the ending so that e.g. “so that I can save time when retrieving previous shopping”. Questions about context can also be recorded in the conversation.
“5.The full use case set shows that the investigators have throught through every user’s needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: “And is that everything?” She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)”
An agile team doing regular deliveries and a ba with good stakeholder management should potentially be able to work through every users changing needs over the course of a software project; the completeness question is probably hard to handle as the system ideal completeness will evolve over time. Validation can be done iteratively in this way and react to change effectively.
-by Arran on 8/6/2010 at 2:12 PM
I’m curious about this text here: “These days, iteration/sprint lengths are so short that it is not practical to implement an entire use case in just one of them.”
Well, I’m a big fan of only “ONE user goal per use case” (delivering tangible value to business). I believe it brought the ideal granularity to work with inside Scrum. My use cases tend to have around five steps in the main scenario and from 3 to 6 alternative flows.
In this configuration one 5 people team is being able to deliver 4 to 7 use cases every two weeks.
If a use case is taking more than a sprint to be delivered, aren’t we talking perhaps of a use case that could be decomposed and the resulting UCs still deliver value if executed isolated?
-by Claudio Br on 11/12/2010 at 1:49 PM
I would love it if what you say is true, Claudio. Can you share an example of a use case that takes 1-3 days to complete? Mine seem to be bigger, so maybe there’s something to learn here. Alistair
-by Alistair on 11/14/2010 at 1:27 AM
If Agile is used for the software development lifecycle, then the problem I have is developers are not really interested in reading long documents i.e. 12 tables of use cases. If a project has similar requirements as a previous project and you are working with a e-commerce product platform already in place, then use case “customer logs in” is not necessary and states the obvious, as the developer already knows how to develop the login page.
Should these type of requirements go straight into a product backlog instead? Can a customer be the reader of a use case document for sign-off?
-by Vanessa on 2/22/2011 at 11:59 AM
I followed a link endorsing the usefulness of use cases and landed here. Glad to find you Alistair.
When I first read about User Stories I was very skeptical of their usefulness particularly after the evolution of Use Cases—-the way you evolved them.
All the reasons you have given are obvious (to me) and they did not have to come from you. But since you have done it, we should see the end of User Stories soon. Or has it already happened? I would celebrate their demice.
-by Putcha V. Narasimham on 7/4/2011 at 6:25 AM
Hi, Putcha. User stories are very much here to stay. They are the new equivalent of numbered requirements or feature lists. The question now is how to balance the utility of use cases with that of user stories. Most people think they serve the same purpose and are therefore competitors, when in actuality they are like a hammer and a screwdriver, complimentary tools. What I wish for is not the demise of user stories, but people learning balance in using the tools available to them. Thanks for writing, and best wishes. Alistair.
User stories only make sense in agile projects. Only in agile do we:
- commit the order of work with respect to business value only
- base how much to complete in a time box on a calibrated sense of “bigness” rather than aggregating projected work from up-front analysis.
- shamelessly admit at the beginning of every time box that we can’t guarantee delivery of everything we plan to do in the box but that our historical data suggests we’re somewhere near right.
- don’t pretend to know up front what stories we’ll discover along the way or which ones will become a part of a business release cycle but only that we will do the most important things first as we become aware of them and shipment can occur when the organization decides we’ve created enough value to make business occur.
User stories are there to drive that style of work.
Use cases make sense – after we’ve committed work, have started the time box, and are performing analysis – whenever they answer a question to which we need the answer. I’m guessing that’s a lot of the time.
-by Lupestro on 8/5/2011 at 2:30 PM
I use “User Stories” as a “very brief description of the use case or as an expanded use case title” :)
Both can go hand-in-hand.
-by Dhruba Sen on 8/5/2011 at 2:31 PM
I use “User Stories” as a “very brief description of the use case or as an expanded use case title” :)
Both can go hand-in-hand.
-by Dhruba Sen on 8/5/2011 at 3:08 PM
We’ve been experimenting, and with excellant results, combining use cases with user stories. One one project, we first write the use cases, then write thin user stores that refer to them. Example: we might have a user story for the Basic Flow, one user story for an Alternate flow, etc. That way, we can size and prioritise the stories into sprints, and always go back to the use case as a measure for completness.
In another project, the user stories are written first, albeit coarsly, then packaged and built into cohesive use cases.
I might add that I might deviate from other BA’s in that I attach, as an appendix to our use case, all the other ingredients – like data defintion (from a business perspective), decision tables, and if necesary, crude wireframes.
-by Dave Levitt on 5/4/2012 at 2:59 PM
Hi, Dave – thanks for the notes – yes, agreed on all counts. “Attaching” those things to the UC works, whereas “embedding” them doesn’t. again, thanks for the note.
Great article, interesting read.
Do you feel that User Stories (including epics) can’t constitute the same completeness overview?
Up-front estimates are notoriously difficult to accurately provide regardless of approach. If you suggest writing out full use cases to facilitate this, waterfall style, you risk the estimate changing with requirements or locking the stakeholders into said requirements. I’m not sure what the answer is here.
Use cases can work in an agile context, of course. Writing them JIT and getting the granularity is the key to making this work I think. A big use case is much like an epic story – it needs to be broken down… That or the sprints you describe are too short. It’s a question of size and velocity here.
Have you experienced User Stories with clearly defined acceptance criteria, defined / explored prior to implementation as the story moves up the stack? BDD methodology introduces scenarios which addresses a lot of the issues you describe:
Given: DEFINE CONTEXT
Given: DEFINE VARIATION OF CONTEXT
Then: VARIATION OF OUTCOME
This language is really nice to communicate, and it ensures that people are thinking about the right things.
Food for thought!
-by Tom Tom on 8/17/2012 at 7:20 AM
I am working in a company that has no methodolgy they claim. Through experience I think it is Waterfallish. As part of my responsibility I am to help them come up with a methodology. After being in the company and observing their habits and client reactions, I think Agile Scrum would serve them well. However, I am a huge fan of Usecases and know that they are needed to communicate especially to offshore QA! I like the idea of creating a User story then use case. Any further suggestions will be greatly appreciated!
-by Great Education! on 6/5/2013 at 4:55 PM
Use cases in practice allow to create ‘complete’ requirements. It is possible to do despite most people think. By ‘complete’ I mean good enough to answer all developers questions and to produce product that enable high performance of it’s users. Usually it just takes a lot of time to create requirements. I keep spending too much time on writing requirements. I usually deliver use cases and detailed requirements too late. However in each project where requirements took too long the project finishes on time. Development goes really fast when developers know what is the purpose, how the functionality will be used, what are alternative scenarios and what exception handling they have to think about. They have most od the details defined when they start so they can design architecture that doesn’t need much changes later. There is very little rework.
Also very important think is support after the project is delivered. With carefully modeled functionality through use cases support needs are much reduced.
-by Łukasz Pasek on 7/23/2013 at 3:41 AM
I was coaching a team that was struggling on reaching consensus on the big picture because they were getting into the “story card hell” (Shore, 2005). After over a hour of discussions, I proposed to draw a UC diagram and every went smoothly after that. I found UCs more intuitive that user-stories (epics) for identifying high-level capabilities at the beginning of a project. Once we have high-level PBIs represented as UCs we can slice them into stories as it’s now proposed by Use Case 2.0.
-by Melvin Perez on 6/18/2014 at 3:42 PM