In a thread about estimation in hours and whether it's a good idea (IMO it's not the best idea by far), this morning Robin Dymond tossed me this challenge:
You have advocated for years that teams should be able to slice stories to the point where they can complete a story in a day. My request is that you show the Agile community how to do that in writing and some exercises that use non trivial examples. I would appreciate learning more about how you do this.
Here, off the cuff, is one reply:
Single Acceptance Test
The most elegant way to do this that I know of is to consider acceptance tests for the feature. Then do them one at a time, simplest first. I first became aware of this idea from Neil Killick (one of the #NoEstimates guys), though I’d like to think I’d done it automatically a million times.
But there is another fun way.
One Dumb Idea
I’m often challenged to come up with something that could be done, even in a week, and that would look like the product. It’s rare that I can’t come up with something. But what happens next is what’s interesting. An example, from memory, cleaned up a bit to make the story clear at small expense to the facts:
Chet and I were visiting a cable TV company. Their challenge was about something they had already done, the old way: “What if our product was pay-per-view movies? The viewer has to be able to select any movie from a menu of them, watch the movie, pause it, wind it back, …” They went on and on. Then they said, “There’s no slice of that that could be done in a week.”
We talked a bit. I asked, “At the beginning of this project, did you have the ability to play a movie over a channel?” They said that they did, because (of course) they had movie channels playing all the time.
So I said, “What if the first slice is that you’re playing some movie on some secret channel, all the time, and if the viewer wants to watch it, he clicks that channel. That would nearly be done already.”
Some of them hated that example. Some liked it. There were lots of objections to how one could imagine that as “done”. The objections were all about additional features of pay-per-view: “He doesn’t get to see the movie from the beginning.” “What if he wants a different movie?” “What if we don’t know his credit card?”
Chet and I probably said a few times “Well, rewinding the movie is a new story,” or “Not switching to the secret channel without his credit card is a new story.” I remember that at one point we said "What if we started just using your boss's credit card for everyone?"
Pretty soon — in minutes, not hours or days — some engineer in the room said “Well, that wouldn’t work, but what we could do is …” and described something they could have done.
That’s what always happens. Someone comes up with a stupid example of a story that could be done in a day or a week, whatever the then-current target is. That someone is usually me, because I am full of stupid ideas and I don’t mind putting them out there.
Suddenly things change. We’ve gone, in one step, from “impossible” to knowing a stupid, but possible, thing to do. The tone of the meeting changes, instantly, from “no way to do that” to improving the idea or bettering it.
Chet and I have done this, time and again, separately or together, in domains of all kinds. One dumb idea that could almost work is enough to switch the team from “can’t be done” to “yeah, but this would be a better way.”
The Real World
Referring to Alistair Cockburn's "Elephant Carpaccio" exercise, Robin said:
I am familiar with Alistair's elephant carpaccio, however his exercise uses a calculator, and developers just don't think the example is applicable to their problems.
They always think that
A million examples, not in their domain, and they’ll still think that.
Yes, but in the real world, we have to deliver every movie ever recorded, to anyone’s house, in real time, together with all the reviews from the major outlets, with or without surround sound, wide or narrow screen, 3D or flat, with subtitles in every known language including FORTRAN, color-enhanced to support red-green color blindness, using every major credit card plus any authorized Canadian grocery store coupons, with the naughty bits either covered or enhanced, with pause and zoom in available, in fast motion and slow motion as well as regular everyday motion, using no wires or cables of any kind, without emitting any electromagnetic radiation on any spectrum, delivering to any television, computer, tablet, phone, watch, or pinkie ring, at any location in the solar system, with zero delay. You can’t do that in the real world.
Yeah, well, we just did. I doubt it took an hour.
All you need is a stupid idea, or one acceptance test. I’d typically start trying to get one story that a PO could imagine was nearly “end to end”, that can be done in a week. A day probably isn’t something the team can do right out of the box.
Or is it? In our CSD class, we do a real application and we run 90 minute Sprints. The teams deliver multiple stories in those Sprints. Not the first Sprint, mind you. :)
Robin, of course, seemed to be asking for a more comprehensive compendium of ways to slice stories. I think he just wanted me to go away for a while. It might be fun to generate a whole list of examples. They would all have the same characteristics, though. It seems like you have to sit with the team and talk with them, or at least get them to talk among themselves.
My way requires someone to have a dumb idea, which isn't that hard, but it also requires them to say it, which is harder. And -- I'm just guessing here -- they have to be respected enough, or enough of a stranger, to get the idea discussed instead of dismissed out of hand.
Neil's way, doing a single acceptance test, might be better. I'll know when I've tried it a few times. My way is more fun, though. I'm sure of that.