Alistair Cockburn

Time enough for love.jpg

Recent Change Note: What Heinlein might have used for the cover pic for his novel, "Time Enough for Love".

Energy matters

Doesn’t even matter.

Matter is energy.
What matters draws pushes pulls
causes gives energy.
Energy matters.

So it matters.


I matter.
I am energy
That matters
To someone.


`180:© 2014 Alistair Cockburn / / being )

Re: Video of Carpaccio exercise

The video is blocked. (at least in Norway it is)

-by Niklas Bjørnerstedt on 2/28/2011 at 3:13 PM

Same in Italy: the video is blocked. That’s a shame, it looks very interesting!

-by Matteo Vaccari on 5/21/2011 at 1:39 PM

hmmm, yep, here’s what I get : “Recording and Viewing Blocked:
Click here to see available content.” ... Click Here refers to it leads to a list not showing my video. found this URL:

-by Alistair on 5/22/2011 at 11:40 AM

I checked all links above, I only got “This content is no longer available.” :/

-by Qing on 10/7/2012 at 5:10 AM

arghh bummer. I’ll peek around a bit when I get time. sad.

“This content is no longer available.” for me as well.
Is there any chance to see the video anywhere else?

-by Gian Carlo Pace on 6/18/2014 at 5:58 PM

Nope. I neither taped it nor stored. At the whim of the owners. Sorry :(

f8cking beautiful

what do u do when it’s so f8kng beautiful nd
u can’t take it all in nd it’s right there where
everyone cn see it but they don’t nd
u stare nd stare nd try to memorize it nd
want to lie there nd sleep there nd wake there nd
live there nd stare nd stare but ur eyes r 2
small nd your body is 2 small nd yr mind
is 2 small so u stare more nd try to hold it nd
u know u finally have to turn away

and it will still be there tomorrow, when u aren’t.

175: copyright 2013 Alistair Cockburn

Re: Why I still use use cases


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 . 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

Hi there,

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

Hi there,

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:

Feature 1

Scenario 1


Scenario 2

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

Collaboration Cards

Based on Collaboration: the dance of contribution (discussion: Re: Collaboration: the dance of contribution) I constructed poker-sized cards of the key entries.

How to use the collaboration cards

You can’t buy now, because I don’t have a way to mail them to you at the moment :(.
This will change when I find some way to do the mailing etc in a reasonable way.


(If you don’t want to buy them, you can print out the image and cut the paper into card-pieces while you experiment with them. Best wishes.)

Here is the image of the cards.


a class=”foxycart lozenge” href=””>Buy Some Now/a> a class=”foxycart” href=””>View Your Cart/a>.a class=”foxycart lozenge” href=””>Buy Some Now/a>

Re: Use Cases to User Stories course

Sounds like an interesting course. I would like to know, when, where,how much information.

-by What’s the Price on 6/5/2013 at 4:17 PM

Still trying to figure out why anyone still uses Use Cases to create new code. Totally see how they document existing system interactions. Can’t we just use Story Maps, Stories, and Architectural Models (aka Construction Models) to do this job? Have you written anything new on this and if you have, can you point me to it?



-by Holly bielawa on 6/3/2014 at 1:36 PM

— Hi, Holly, please see Why I still use use cases (discussion: Re: Why I still use use cases). bests, Alistair

No center to agile

John Rusk recently reminded me (his words):

“Agile” (in the manifesto sense) was intended to capture the essence of a bunch of similar methodologies,

some of which were very conscious of reducing the cost of change (XP),

some of which were conscious of reducing the initial cost of development (Crystal’s efficiency),

some of which were focused on the social structures of teams.

The essence was none of the above. It was about successfully producing software, and a better understanding of how that should be done.

John here reminds me of something that I periodically forget – we all came to the meeting ‘’with our own value sets’’ and found an area of commonality across them.

This means that finding the “true center” of agile can’t be done. There is no “center” to agile development. There’s only proximity of similar-but-different personal value systems coincidentally producing similar recommendations.

It’s a bit like the “old towns” in Europe. The old town is the center of the city, but the old town has no center itself – it’s just a ‘’maze of little twisty passages, all different’’ ( “Colossal Cave] :-). From far away it is pretty easy to say, “The ‘’center’’ of the town is in that direction”. But once you get into the old town, if you ask, “Where is the center?” you’ll either get no answer or many answers. (As Gertrude Stein [> wrote href=”” target=”_blank”> “there is no there there”)

Exactly as we see with agile development. From far away, it is easy to see in which direction the center of agile development lies: deliver more often, shorten the work-in-progress, increase communication, lighten the bureaucracy, etc.

But once you get “about there”, each expert will give you a different answer as to how to get “more there”. That’s because each expert has their own preference as to what the center might be. John Rusk listed three up above; there are certainly more.

I’d suggest first getting “close”, by following the Agile Manifesto as written. Once you’re close, some soul searching by the people involved will help you discover the many centers of agile, and the only true test of direction is what helps your organization the most.


I like this “admission.” I often meet people who will not try something like Agile or wiki or whatever until I can provide them the one, true, all-consuming, all-something-or-other, single thought that is the center of everything. If that single punch-line doesn’t exist, they won’t try the approach.

There are a few ways to deliver satisfying software. There are a multitude of ways to making a mess while trying to deliver software. I find the same statements hold for many fields of endeavor.

Dwayne 04:15, 6 January 2008 (MST)

Re: Self-organization means mutiny

Search for: “Amazon offers workers $5,000 to quit, but it’s not crazy” for a real world example!

-by Andy Masters on 5/13/2014 at 9:37 PM

thanks :)

Mark Twain quote

“When I build a fire under a person, I do not do it merely because of the enjoyment I get out of seeing him fry, but because he is worth the trouble. It is then a compliment, a distinction; let him give thanks and keep quiet. I do not fry the small, the commonplace, the unworthy.”

Mark Twain’s Autobiography 2011 edition, p221

Re: The Advanced Agile Masterclass Tour

Ola Alistair,

Wondering if you have any plans to come to London with this tour?


-by cuan on 4/22/2014 at 5:27 AM

might be: I’m working with Gabrielle Benefield on one. Might be in September. Could you please email me at so I can keep you posted? thanks