You write a use case as a series of connected sentences, like a little story. You pass them around the organization and then everybody reads them. They take no training. You just send them to people and they’ll argue with you. They’ll find a hole, which is what you want.
Are use cases an essential partner to user stories for Agile teams? Agile Manifesto co-author Alistair Cockburn thinks so. In this episode, Richard and Peter discuss use cases and user stories with Alistair, including some practical steps to get started with lightweight use cases as a complementary tool for your Agile product development.
Connect with Alistair
Learn More
Interested in learning more about user stories? Check out Humanizing Work’s free Guide to Splitting User Stories and our new online 80/20 Product Backlog Refinement course.
Episode transcription
Peter
Welcome to the humanizing work show. In this episode, we’re talking about use cases with Alistair Coburn, coauthor of The Agile Manifesto. Alistair has been writing about use cases since the 1990s and we wanted to get his take on how they fit in with user stories, something we’ve written quite a bit about. In our conversation we cover the two key benefits of use cases compared to user stories; how and where the two ideas overlap; how to get started writing a use case in just a few minutes and how use cases often function like a fast internal validation test of a big idea. But before we jump into that conversation with Alastair…
Richard
This show is a free resource sponsored by the Humanizing Work Company. Humanizing Work exists to make work more fit for humans and humans more capable of doing great work. To that end, we do training and coaching in three areas. One, we help leaders lead empowered teams and individuals more effectively. Two, we help product people turn their ideas into good experiments, visions, and backlogs. And three, we help teams collaborate better to produce meaningful outcomes on complex work. If you or your organization would benefit from better leadership, better product management, or better collaboration, and if you find our vision for human centric work compelling, we have capacity to take on a few new clients in 2024. So visit the contact page on humanizingwork.com and schedule a conversation with us.
Now over to our conversation with Alastair Coburn:
Alistair
Humanizing work. Are we going to humanize work?
Peter
Humanizing work time. You wrote your first book on use cases, what, 25 years ago now, coming up on?
Alistair
Well, so the irony is in 1990, like to 93, I needed to learn use cases because I was writing a methodology for IBM and I went to Sweden—Stockholm– took Ivar’s class, came back, but I had to write up a guide (an instructional guide), for the IBM people. And Ivar’s course, wasn’t like, sharp enough that you could literally, like, teach it and roll it out.
So I kind of cracked the code with the goal levels. You know, I’ll refer to goal levels a lot. That was in like 93, 94. And then I went to a workshop with Ivar and Kent Beck, Jim Rumbaugh, Martin Fowler–like all the peoples. In 94, I was still an IBM employee. And I watched everybody not understand use cases.
And I had the answer because of the goal levels. And I wasn’t allowed to speak because IBM had deemed it IBM confidential. And I was like, “Argh!, I can’t say anything.” And I watched everybody, went like this, and I was going, “But I have the explanation!” So I wrote a paper in 94, you know, when I could, about that and I thought I was done.
It was like a ten page paper. It’s still on my website. It’s called Structuring Use Cases with Goals. And it answers basically all the hard questions, and I thought I was done. And then in like 99, there were so many books on use cases coming out that I realized that if I didn’t write my own book, I would have to teach out of someone else’s book.
And they were all crap. They were all rubbish, right? And so, like, as a matter of self-defense, I just literally wrote as fast as I could. And the use case book came out in 2000– end of 2000. I’m writing a book series called Simplifying. I’ve already written Simplifying Software Design. There’ll be simplified project management, simplifying use cases. And then Ivar Jacobson kind of called me up one day, and he’s the father of, inventor of, use cases, and he says, “Hey, I want to get use cases back on the table. Co-write an article with me.” So we co-wrote the article and I go, “Dang! Now I really have to get on this book because I really; yeah, I have to get this correct. I have to get it now.” So now I didn’t like that number, 25 years, Peter, but 24. Okay.
Peter
Pretty close. You probably started writing at 25.
Richard
Right.
Alistair
1994, so 30 years ago is when the goals concept came out. And in my new book that I’m writing, Unifying User Stories, Use Cases and Story Maps. Concept one is verbs have time durations, and if you can’t master that, you got nothing. And the next one is verbs break down into smaller time duration verbs.
And that’s the short form, right? But everything is goal oriented. So we’re writing a spec for a system, right? We’re not writing a love novel, right? There’s no descriptive passages. It’s all action based– action verbs. Right? And so you’re trying to say the user has a goal to accomplish this, or maybe the system has a goal to accomplish this.
Every action you state is presumed to succeed. So every goal has, of course, sub goals and steps. Or how do you do that? Right? Break it down. And every time you break it down, by definition, if you have a goal that takes that long, the steps are going to take that long. Tick, tick, tick, tick, tick, tick, tick.
And the magic that’s missing in all of the literature (all of the literature!) is a reference to these user stories, story maps, use cases, epics, same as features, everything. Everything’s got this, this time duration concept and processes break into sub processes and we all know that. But when we write verbs, people don’t play with that explicitly. So that is like the first two concepts in the book.
What I did in 94 was I cracked that code like that; and you could keep breaking it down forever and you never invade the system. So when I teach it, people think if you break it down, you’re not going to look at the internal design of the system. No, you just take, you know, eventually it’s like you contract your muscle in your arm to–, right?
You get these really tiny, tiny goals, verb– action verbs– that happen. So we even wrote (we literally wrote) for Use Case in my class, I let people experiment with stuff, “Insert card into ATM.” Literally, we took it into that granular and you don’t have to invade the design of the ATM to write that use case. It’s all externally visible activities and that is so foreign to people as an explicit concept.
And that is the anchor for the whole book is first verbs of time durations, split them up all action verbs into verbs with smaller time duration. You can do that essentially forever. And the only other thing you need is that aside from verbs, when you go to decompose a use case or user story, you decompose everything.
Everything. The data, performance, scalability, UI, right? Everything. And use cases only handle the verb part and user stories handle all of them. So when anybody makes a flip comment about, “Oh, use cases are just like a user story with (right?) or user story is just the use case with…” right? They’re missing the point. There’s a point of overlap, which is the verb, and then use cases do this with the verbs. Explicit breakdown of the verbs and user stories don’t. But user stories cover–break out of everything else. The use cases don’t.
Richard
What do you mean when you say everything else, Alistair?
Alistair
Data. So for instance, you have a use case– I gotta do a use case– didn’t matter. Use case, user story. To me, when you understand about the verb thing, there’s a harmony between them. And then you look at the Venn diagram and you just move around, right? So we just say something like “user updates the customer profile” or whatever, or system.
They authenticate themselves. The system pulls up the customer profile, right? What’s in a customer profile? Well, you’ve got name, address, phone number, you’ve got whatever security clearances, you’ve got reward points, you’ve got all that stuff that’s in the user profile. You don’t need all of that to get started. So when I say decompose that. You only need the name.
The data needed is enormous. The data you need to get started is tiny.
And the presupposition on all of this is we’re going to do fine grained incremental development. If you’re not going to do fine grained incremental development, that’s not the topic. But we’re all pretty much doing fine grain. If you’re using user stories, if you’re doing anything online, you’re doing fine grain incremental development. So then we say, “Okay, what about the UI?”
“Oh, I don’t know. Let’s just get one of those little tools that makes a, you know, mock UI that’s sloppy, but you know, or looks all wiggly because we don’t want people to get attached – you know. Whatever.” They will put buttons all anywhere. Well, we don’t need all the buttons—actually. We only need the button for… Well we actually need the UI for the first name, for the name of the person, just first name, last name. Right. And we don’t even care where it is and a GO button. And we can add that later. You know, we know that’s going to happen and the UX people can be doing the master plan of having– making all the things just beautiful, and consistent stuff when you’re rolling with a UI like that. So that’s what I mean by decompose everything. The UI’s fractal. The data is not fractal, but it’s, it’s, you know, it’s nested.
Right. What about performance? Well, I don’t care. Make it not horrible and we’ll tune it up later. What about security? What about– What about– what about– what about. Right? Ease of learning. What about– right? And none of those are in a use case, but you can make user stories for all of those, and people miss that. Right? So the use cases, they have two super-duper values. And the one is you pass them around the organization everybody reads them. They read like a story. They take no training. You just send it to people and they’ll argue with you. They’ll find a hole, which is what you want. Right? I have friends who are black belts in story maps, and I look at their story maps and I go, “Ooh, that’s nice.” I still have to read horizontally one verb phrase at a time and attempt to construct in my head what is the scenario? What’s going on? You write a use case as a series of connected sentences, like a little story. One, two, three, four, five, six. People read it, just they don’t think about it. It’s they read it and then pass it around the organization and then everybody…
So the use case as a text form and I don’t do graphical use cases, I really dislike them. People say they’re, you know, visually oriented. I have yet to lose like an AB test contest of my written use cases versus any graphical tool. Again, I go there and there’s a graphical tool and you’re reading these sentences around in a circle attempting to construct a coherent story in your head and you’re looking for holes and mistakes, but you spend so much cognitive energy literally just trying to put the story together, you can’t find mistakes. I’m happy it feels good to like, spread it all out and make it look cool. But when you pop it up on the screen, I watch people go like this because they go, “By God.” Right?
Peter
I’m a very visual person. Between Richard and I, Richard likes to write. I like to draw. If you were to oversimplify it, I don’t see any particular need to visualize a use case. They’re short enough, they’re connected enough.
Alistair
Craig Larman wrote his book and we had a long thing. He said, I’m a visual person. And I said, Try this. He goes, “Yeah, you’re right.” On the other thing that use cases do, is they’re a completeness test. We’ve developed a discipline for how to find the holes. So you write the thing and then you go, “Does that really come after?” I mean, like, we’ll be staring at it 20 minutes. I’ll go “Wait. Between step three and four, don’t you have to…” Right? And you brainstorm a list of failure conditions. “Oh! I didn’t think about that. What are we going to do in that case?” Right? So user stories have got zero on that.
Story maps are halfway there. I used to live a mile from Jeff Patton in that like 2003 to 2008 timeframe. So we’d meet at coffee shops and debate and he was developing story maps and the really good story maps that I see that they’re pretty good but there’s no discipline in how do we find the holes? So my book, the book that I’m working on, the stuff that I’m working on now, is how you just flip back and forth. Anyway, back to the just to the verb levels.
What I want to say is the readers understand this about verb levels. Verb durations, I call them levels; altitude levels. Right? They all just get uncomfortable if you don’t match the verb levels in a scenario. If you have something that takes a long time followed by something that takes a short time, they can’t articulate it because nobody knows about this, but they get confused and you watch their–you know, they’re just not comfortable.
So the drill practice is to learn to kind of level the same. They’re describing a process and sub processes. You don’t have a one month process followed by a five minute process step. Yeah, right? Anyway, that’s my intro, and I know it took a long time, but that’s the punch line of what I’m aiming for. And I hope that people who watch this really get the thing about A, the thing about the verb levels and they decompose and, B everything decomposes and C the use cases and the user stories really only have a tiny zone of overlap. Richard, you’re looking really thoughtful; I’m dying of curiosity.
Richard
Yeah. Well, I’ve spent most of my career writing about and teaching user stories, and so I’m kind of trying to puzzle it all together and think about how use cases may fill in some of the gaps that the people I work with experienced there and how that fits in. So it’s been fascinating.
Alistair
What kind of gaps would you see?
Richard
Well, I think the way we talk with people about decomposing work and making sense of what you need to do is kind of a big idea that you have a vision for, then breaking down into minimum marketable features and accomplishing a larger goal. That may actually involve several verbs because there may be multiple actors– things that need to happen.
Like I want to be able to borrow a book from my local library. There’s some things I do. There’s some things the librarian does, there’s some things systems do, but there’s some minimal amount of those that comes together and then break that into stories. But I think there’s a thing that sits alongside that. What you’re describing with use cases that allows us to reason about completeness in the behaviors.
And we may never build it as a whole use case, but it’s allowing us to think about what are all the things we should be considering here, and then which of those belong in any particular minimum marketable feature.
Alistair
And let me just ask you a question. What happens if you go to get a book and it’s marked as being in the library, but it’s in fact, not in the library? When does that user story show up?
Richard
Usually by accident when you run into it. And so this is exactly the kind of gap.
Alistair
But my very first project where I was forced to use user stories and we look for failure cases, right? And these things hurt so badly. And because I’m telling it against a colleague, I can’t name too many names, but it was a commercial system where I was selling something having to do with courses. And this guy, there were three of us, right?
Total of three of us. There was me. I’m the business owner. And this guy was a very sharp, agile developer, but his programmer was in Egypt, and the very first thing that happened was some client did a course, and was supposed to pay, and says, “I went to log on.” And it’s like a Wednesday night or Thursday morning, Wednesday night, whatever.
He writes to me, he says, “I went to log on to do the registration of payment, couldn’t remember my password. There’s no reset password button,” you know, click field, you know, can I get that? So I write to my friend. I go, “What do you mean there’s no reset password thing? Can you get that?” He goes, “No, because in Egypt, they’re 9 hours time zone ahead.”
Thursday morning in Salt Lake City is Thursday night in Egypt and Friday is their Sunday in Muslim countries. So that’s their weekend starts. So he was gone. So when I get up on Thursday morning, there’s no work happening. So I don’t get anything until the next Monday, so I’m shut down four days a week. And so I asked him; I said, “But how could you have this thing and no reset password?”
He goes, “There wasn’t a user story for that.” And I went, [expletive bleeped] “Pardon my French.”
Richard
(Laughs)
Alistair
“What do you even mean? What do you even mean?” Right? So I’ve been hurt with these holes. And in the olden days, 24 timeframe, even black belts and user stories that come up with the project estimate, they’re not being off by a factor of three easily. I mean, there was no correlation between what they said and what it took because you haven’t got any flavor of completeness check.
Richard
Right. So there’s no mechanism for that other than perhaps teams that are doing something like behavior driven development, where we do reason about examples that are outside of the happy path. But that’s happening at a way more granular level. And you have these extra failure case stories popping up in the middle of a sprint and ending up on the backlog.
So it doesn’t help you at the big picture level.
Alistair
Yeah, So this is my agenda. And thank you, Richard, because that’s– like I say, the two things are you pass the use cases around and especially the high level ones, not the lower level ones. And literally the execs are reading it saying “Yes, no,” finding holes. I took one on a project to the exec and he immediately found a hole—immediately. Like it was a page and a half kite level use case.
Brilliant, sweet. It turned out what he found was out of scope of the project, but he was about to start a meeting, I said I said, Hey, look at the use case I just wrote. And he goes, “What about automatic warehouse triggering?” And I go like, (zap!) flashlight– and like this– turned out I was out of scope, but it took him that long, right?
That you find holes that fast. Then the testers get them. They know what they’re supposed to get. The business people get it. They know what they’re supposed to get, right? So that even kind of, let’s say, sloppily written use cases hold together the entire organization. For me, that’s the biggest, biggest–it’s like $100,000 value. And then the second, the $10,000 value, is this completeness thing for the just that the product owners or business analysts stay ahead of the programmers investigating things, so when they ask a question, they have an answer. Those are the top two. And I don’t hope that, you know, people are just going to go old school and write all the use cases. So that’s why this learning to just shift back and forth.
Richard
Do you have some kind of heuristic that you use to help people prioritize where to write use cases if you’re not trying to do it across an entire thing.
Alistair
Yeah, it’s called the brain. And use cases just like user stories and sorry but they’re supposed to be collaborative between the business and the programmer, right? So if you have the business people writing them, they’re not trained in exact thinking. So they’re sloppy and they make mistakes and they don’t understand technology and it’s fuzzy and ambiguous.
If you have programmers write it, they write it from what a friend of mine calls inside the bottle. They can’t get outside the bottle to look at the bottle. Right? So it’s all tech, and contains design and it’s too—right? It doesn’t make… So you really have to have a conversation. And it turns out not to matter who owns the keyboard, right?
The business person can own the keyboard or the programmer, but. But it has to be done that way. Right? Now you’ve got that conversation and you’ve got the business person will say, “Hey, what about splitting credit card? You know, we have to [split] across two credit cards, right? Or the programmer will say, “What about when the system goes down?” or what about, you know, that they’re brainstorming.
And now let’s say in the olden days we used to like kind of write out the whole use cases. Now I go “Write the main success scenario, brainstorm all the weird conditions, failure conditions, alternative success paths. Just write down the conditions. It doesn’t take long. You brainstorm it and in 5 minutes you write as fast as you can.
Now you stare at those and say “Which ones are going to cause damage? Which ones are interesting, which ones can be deferred? Don’t need- don’t need– don’t need–don’t need; later—later. Oh, well, you know, “Oh, I hadn’t thought about that.” And a failure within a failure is really where you get interesting trickiness, right. You say, “But what about this? We do this, this, this. But what about if that goes wrong?”
Oh yeah, yeah. That does happen occasionally, right? So this is the discipline that we’ve got around the use cases. And nowadays I would totally energy manage right? brainstorm all the use cases, write a kite level use case. But that’s the macro process across users like the backbone in in a story map. Right?
Write that. Break them out brainstorming list all day you got to brainstorm 20; 30; 50 use cases stare at ‘em, pick out ones like which one is the key one that we really want to do. Wright that main success scenario, brainstorm it. And now you’ve got a ton of information. Now you take the kite level use case, you put them across the story map like you’re supposed to.
Each one of those tasks, you know, you break it down, you put the failure conditions or the sub steps if they’re tiny, right? And now you’ve got your kite, poof, exploded on to your story map or user stories. I don’t know any other discipline. That story maps that’ll help you do this. And then you’re going, right?
Then you cut up and split up and do all that stuff.
Peter
The thing that’s particularly elegant about this to me is that I think use cases function in the same way that like, in the Lean startup community, a validation test does. It’s a very light, lean thing that allows you to test your hypothesis of what are we building, how big might it be, what will it do for whom? But the way you’re describing it is very lean.
And now you can go, just bring that to the exec as a test in lean startup terminology.
Alistair
I’m going to just blow my own horn here. If you write use cases the way I do, you win. If you don’t, you lose. It turns out I used to think they were very simple and I found out that this is a really narrow path that’s really hard. People want to get adventurous. If you don’t, no. It’s like a cliff on both sides: The way to write it. And the giant failure of use cases, when they came out was people would write what I called the encyclopedia, all this stuff it’s good to know and you need to know to implement it. It’s a great place to hang it onto a use case, but it ruins the use case and so people would take forever and they’d say the use case is the encyclopedia.
And I would say back in the days of paper, was “No, make a one page use case– two pages at the outside, take the encyclopedia and it doesn’t matter if you repeat the 12 sentences on the first page across 30 pages of encyclopedia, but staple them together so that the easy to read thing’s on the front.” But people didn’t do that because of the heavy weightiness and you know, everybody hated them. Right, fair enough. And they would all sell them all the completeness all upfront right, so now you’ve got a big block. [Yeah.] So part of what I hope to teach the new generation: Don’t do that. Write the sentences, brainstorm the failures, always less than a page. Stop. Do a couple of those and now you sit there and use your brain and you do incremental development and all the rest.
So that’s the shift the use case community has to make. And that’s the shift the agile community needs to make.
Richard
It feels like the environment is better for that now than it was in the nineties. I think the quarter century of incremental dev…
Alistair
Well in the nineties almost nobody was doing any incremental development and in the aughts nobody wanted to touch use cases because they were heavyweight waterfall and so they made the user story mess and then Jeff Patton you know packaged that up in some of this hybrid thing that’s pretty close that gets some of this and some of that and it could be because there’s enough people complaining they can’t see the forest for the bark on the trees.
Peter
Yeah. There’s something in this that I wanted to tease out which is that the way I would describe what you’re recommending is “Get the minimum precision to test for accuracy.”
Alistair
And, you know, I, know that and you know that. And that’s absolutely correct. And nobody else understands what you said. So can you explain that.
Alistair
100% correct when you do it.
Peter
When you describe the 25 page, highly detailed use case, that’s way too much precision before you’ve actually tested, “Does this actually have this goal? Is this the major success path? Are these the ways that it could go wrong?” The alternate paths, here; we haven’t even tested that yet, so we don’t even know if it’s accurate before we’re adding a ton of precision on top of something that might not be accurate.”
Alistair
Yeah. So for that, for the listeners, the way I phrase it is precision is how much you care to say. And I phrase it that way because sometimes even after you’ve done the design and you have all the information in the world, you roll it back up for a different audience, right? Your execs, your business, your user, your whatever.
And, and so you could have like I know pi is 3.1415926535, etc. but you don’t say that. The main thing is it’s not 73– it’s three. It’s about three. So at the beginning you don’t know enough to say a lot and this is what you’re saying. What’s important on the word “precision,” is later when you’re presenting to other people, they don’t want to hear all that.
They don’t want to hear that, you know, two meters is whatever, 6.14 feet. They don’t want to know about that point one four. They don’t care. Now, we do that with everything. And you do that with– take the data, right? I did that with the data level one data like the integer part of pi is customer profile information.
Okay, cool. It’s not that whatever else there is, you know, but it’s customer profile information, just like the three. Well, that’s got, you know, name and phone number and password and stuff. That’s 3.1, right? Now, but name is first name; is middle initial optional or not; that’s 3.14, right? And you keep adding. So for people, if you understand that now, what you said, Peter, is you sketch out a use case that people say “I don’t want that.” All you did, like the name of the use case that we’re going to support this goal is like the three– the integer part–and I’ve seen people literally have seen people where they brainstormed and listed like — I don’t know, like 120 possible use cases and they cherry picked those down to about ten. They took those ten and they blew them up, actually to smaller use cases. And out of those ten they now had, let’s say 20 or 30, they took like 8. So they used just the integer part to say, this is where we want to focus.
So Richard, for you, right? This is “focus your attention.” This is that incremental thing. Like do that. Then they write the main success scenario, and say it would look like this. And I have a fabulous story after like two days of use case class and the team lead tech person on a project; we actually had people come in from the field; and there was this use case with-whatever- six steps. Right?
And the users said “This is what we want.” On a flip chart was written and this was the end of two and a half days. And, the tech lead said “None of that is anywhere in our project scope,” right? So the very first use case they wrote scribbled it down scarcely one decimal place of precision, and it was like, “No. None of that is in our project scope.”
And everybody stared each other like this, right? I go, “I Think you guys need to talk a bit.” But that’s the precision hypothesis thing is you show it and, “I don’t want that.” So for the people who are listening that the accuracy is, how correct are you when you say it, we’re going to give you this. “No.” Right?
So then you save a lot of time by not elaborating all this stuff. And then someone says, “I don’t want any of that.” That’s to your point then, Peter. Yeah. And Richard Now, because you don’t work in this, I love this that you don’t work in this space and you’re hearing this. Can you just reflect back a bit on where you’re going inside your head?
You’ve got the most– your eyes are just… They’re really going!
Richard
Well, so I’ve written a lot about user stories. That story splitting flowchart is like the most popular thing.
Alistair
Oh my God. By the way, I just want—kudos to you guys– I always have to hunt that up and see if there’s anything missing. Like the first time? Because I tell you, go split the data. Split the data then I looked at your mind map. And I said, “Holy cow, it’s all in there.” So yeah.
Richard
Thank you. That means a lot. so I’m thinking about that piece. And then I wrote a book on BDD as a way of collaborating inside user stories. And the biggest breakthrough for me in this conversation is realizing some of what I like about the interaction and matching accuracy and precision in BDD could be done at a higher level with use cases as you’re describing them, and that solves some problems I’ve seen my clients run into.
It solves some problems I’m running into– like I’m creating software right now for our company. An assessment tool for managers using our three jobs of management model. And I’ve got a bunch of features and user stories and I keep coming up with things I didn’t think of. These edge cases, and I wish I had a better way to model that more comprehensively.
User story mapping has never really clicked with me. My brain doesn’t seem to work that way, and so I’m eager to go write a couple of use cases and see if that helps me find some of these holes and feel better about predicting when this tool will be done.
Alistair
So that’s cool. And I wanted that… A) that’s awesome. And so as a piece of advice and I give this, you know, to you because you’re going to try it out; but for also for all your watchers, don’t worry about the brilliance of the use case. And don’t you have the number of the steps you don’t have to get fancy about the grammar. Literally write, “He does, She does. He does. She does, right? user does– system does– users. And by the way that I’ll put here, I’ve wanted to run a project I probably never will. There’s a generic five step use case. I think it’s five — we’ll see– that all use cases should be and so all the use cases should have just five sentences in them. It’s not completely true, but you’ll see why.
So the user lobs a pile of data into the system. That’s step one. The system validates that it’s all whatever it needs to be. The system goes out to a bunch of other systems to collect whatever collaborative information it needs to get from all the other systems. The system lobs back to the user, whatever resulting pile of information is needed.
The system does any logging update that the transaction happened. I believe you could basically take all use cases and fit it into five sentences or less. So the point– the surprise here– is it goes out to the other system. So use case is a black box specification. User stories won’t pick that up. Right? So what we’re doing is demarcating the responsibility of a system with respect to other systems.
So there’s back end systems that already do authentication. You’re not going to write that code in the new one. You’ll say, you know, “user authenticates,” whatever. It’ll say, “The system passes that along to the authentication system and gets a yes/ no back,” right? So you’re demarcating what’s in and out. So that’s a five. So now I claim and if you’re just playing with this you just write anyhow.
But it’s got [Alistair sings] flow. Right? One, two, three, four, five steps and that’s enough to hold the conversation and do your brainstorming. The value doesn’t come with — diminishing returns sets in early like I can teach you how to write a use case perfect to the seventh decimal place. Like literally, I can teach you that and I can do that, you know, on the fly.
But you can’t, and don’t worry about it because diminishing returns sets in. Write some stuff. Do the brainstorm. You’ve already got like 80% of the value of the use case right away. And thank you, Peter, because I do have a section on precision. I had to add that in to the book and I think I don’t play it up enough later, when I’m talking about the matching, the kite, the story maps and the use cases. So I’m going to have to– I’m in that section right now– and yeah, so thank you for that. That was awesome.
Richard
And I don’t want to open another big topic here, but I think the other thing that’s important about accuracy and precision is that there seems to be a cognitive bias around that, where lots of precision implies lots of accuracy. And I think this was the problem we fell into with big requirement docs and big plans. There’s a lot of detail there: It must be right. And so matching these is great.
Alistair
Jeff Patton used to say, (it was so brilliant) He says “You can’t know all that stuff now. It’s too soon to know all that stuff.” That’s absolutely correct. [Good.] That’s awesome. In terms of the book writing, this has been a fun journey because I’m trying to write it as fast as I can, literally as fast, and I only get one or two hours a day.
So it’s not really fast, but the way I did it was levels of precision, because I work in that manner all the time. So I said, “In principle, if somebody knew their stuff, how many sentences would it take to describe the entire contents of this book?” So I had like six core concepts, three sentences on use cases, two or three on user stories.
I had two on story maps and two on putting them together, right? Whatever. I had like 15 or 20 sentences. So I stared at that like, is that everything? If I said that, is that everything I want to say? And then because I subtitled the book, “You’re probably doing it wrong.” So the original book title was “Agile, meets use cases, uses stories and story maps,” subtitle: “You’re probably doing it wrong,” and that’ll probably get changed to the power of verbs or something upbeat. You know.
But I love–And so I wrote a little table for each sentence and said, what the key idea what you’re probably doing wrong, what the cost is and what the fix is. So then I stared at my twenty sentences and my tables: it’s the precision thing, right?
I go up and down and up and down, and I found later I had to add one more concept, which was the precision thing. And one more thing. Thing, thing, thing. But I still do that now. I just am working on the “I’m putting them all together” part and I thought I just wrote paragraphs. I said, “Nope, go back, write the sentence, make the table, make sure it’s tidy.”
And then the last chapters, literally just all the tables, right? The sentences and the tables. So if you know, if you already know, you just go read those things. And that’s the rolling up of the precision back again, right, for the reader who doesn’t need all the details. So yeah, it turns out that precision thing, very few people can really move fluidly up and down precision levels.
And you do that, you play with the— Oh! One more little thing. In my book and in my classes, I always used to say, you know, “If you say that pi is 4.14159, you’re speaking with a lot of precision, but not accurate. I never got to finish my sentence before people would raise their hand. “No! It’s three!” and even the copy editor in my book, like it’s front of her in the text. I go, if you say…, then you have an accuracy. “No, it’s 3.0.” So, yeah.
Richard
That’s funny. So how can people in our audience follow along with what you’re doing and find the book as the preview comes out?
Alistair
Thank you both LinkedIn and Twitter, and Twitter, is totheralistair. So I am pre publishing, you know, whenever I do stuff. Table of Contents, the 15 sentences, I find a passage I just wrote. I pop it on LinkedIn, I pop it on Twitter. People write back, they like it, they don’t like it. They find an improvement; they find a gap.
So I use– that’s my feedback mechanism. And I’ve got several improvements from the comments that people make.
Peter
Great. Well, we’ll try and send some more people your way.
Alistair
Oh, I had a comment. Richard, Richard, little diagnosis on you and your way of working just in a contextual thing: When you talk, I hear all dev language, what I’m addressing, what should be the case with user stories and isn’t– what should be the case with story maps and isn’t–what definitely should be the case with users. What I’m focusing is on that mental mind transfer between the business expert and the dev expert.
So if you’re talking about cucumber and BDD, you’re already on the dev side, man. I’m sorry, you’re over there, right? and your other stuff. You’re all over here. So my goal for you, (I have a goal for you, haha!) is to move you into the joint discussion space, right? So there’s an equal part, equal energy from the business side.
If you say BDD, the business users aren’t writing that stuff.
Richard
No, they’re not.
Alistair
Right. So, but, so this is important because developers actually drive the industry. So there was one dev group and they said– literally, the programmer said, “If you show up in here with a use case, I won’t talk to you.” Right? They have that right and they’ve done this since I’ve ever been in the business in the nineties, yeah?
So somehow the goal has to be a little bit to get the devs to honor even the existence of both the conversation and this form and get the business people to get good enough at it that they can hold– even if they write the use cases and it’s only for them and they show them and dialog and they cut it up into user stories.
Not a problem. They can babysit. That’s for them. They can cut it up for the others. But trying to get the programmers at least to come partway across and try to get that mind meld; that’s a big, big goal for me. So that’s my wish for you.
Peter
Thanks, Alistair. I know you got to run. We appreciate your time.
Alistair
It was a fun conversation. And yeah, in a couple of months if it surfaces again, happy to do follow up.
Peter
Great.
Richard
Great. It was great talking with you. Thanks, Alison.
Peter
Good to see you.
Alistair
See you guys. Bye bye.
Peter
Thanks for tuning in. If you found this conversation useful and interesting, definitely go check out Alistair’s work and follow him on Twitter or LinkedIn. And please help other people find the show by sharing the episode on your social media.
Last updated