I sort my criteria for a story, so that when I step back from "perfect story", I step in the right direction.
A "perfect" story has several attributes. Each of them contributes to its value in different ways, but maybe before we even list them we have to talk a little about what that value is. Remember our trio, the Made, the Making, and the Makers. Balancing these forces well is at the center of my agility. The value of using stories affects all three, as you’d expect.
Stories affect the Made: remember that most software in the trade is already shipping. It’s already made, and each story is a change to that made shipping thing. The order in which the changes are applied to the made is important, because each one of them alters the market.
Stories affect the Makers: they narrow mental bandwidth, focus attention, provide temporary local language. Though the planned stories may stretch out in the distance, we see them in a fisheye lens: the current story is dramatically zoomed, the rest diminished & distant.
Stories affect the Making: they provide part of "done", they are markers in collaboration, they participate in our ideas of progress and goal and motivation.
A "perfect" story, then, is one that provides optimal benefit across the whole trio. It affects them all equally, and all beneficially.
So then what criteria are we looking for? Here’s how I do it. For same-but-different, try the article from Tim & Jeff’s brilliant Agile In A Flash WHICH YOU SHOULD ALREADY OWN.
(Note: whatever differences betwixt us are all intramural or tonal.)
Size:
My perfect story fits in a regular working day, start to finish. It gets less perfect at two days, and dramatically less perfect beyond that mark.
- Note that I’m not talking about one of those rare wonderful days, either, but a plain ol’ working day, with whatever meetings, breaks, interruptions, brushfires, arguments about cold-filtering or nutrition or last night’s TV show. A regular day.
- Note that I’m talking about a judgement call, too. I hold my thumb up, squint at the story, and say "a day". It’s a reasonable guess, that’s all it is. I accept the reality that I’m going to be wrong about such guesses.
- Note that I’m being purposefully agnostic here on whether that’s a team day or a mob day or a pair day or a person day. For each story, we decide which of those variants we want to take, and go from there. The point of this isn’t making Jira or Rally or whatever balance.
Shippability:
A story is a whole thing I can send to production cheerfully, as guaranteed as humans can manage. It doesn’t break what was already working, it’s tested, it’s stable, it does everything we said it does.
Whether or not I am actually shipping from HEAD every day — in most apps I try to be — when I say that a story is finished, I mean: "you could ship this today and it will not create worldwide panic tomorrow". I am going after everything about the code here, not just its aspects that are visible to end-users. That is, the interal quality, the testing, the packaging, even the deployment, is as excellent as I know how to make it.
User-valuable:
The perfect story is visible to the user. It makes her say, "Oh, cool, this does just what I wanted". She might also say, "Whoa, that is fast," or "Hey, it actually told me exactly why it can’t do what I wanted".
I want to be clear: "User" here is end-user. It is not the maker or makers who tells us what the user wants. I want to strike at every idea that suggests that the people who help us with that aren’t inside the team, aren’t makers. They are makers.
Planning-Useful:
Here there are a few criteria I’m going to bundle together: independent, negotiable, unified.
When we plan using stories, we’re doing something very different than when we’re about to code using a story. The short and somewhat snarky version of this: all sense of crispness, definition, and certainty goes pretty much right out the window. This isn’t mysterious or surprising to anyone except heavy powerpoint abusers. The story-to-code is centered in the fisheye, it’s zoomed up super close. the stories-to-sort are out at the rim. They’re of necessity and by design far squishier.
(We could wish for a world in which the future is as crisp and delineated as the present, as the first forty years of software development theory did. I have an extremely crude saying from my Grandma about that, but I’ll spare you.)
So, for planning, stories need to be independent: no order-of-assignment assumed, negotiable: the beginning of a conversation not the end of one, unified: in service to a coherent business goal. I’m going to punt, for now, on all of these criteria. We can do that some other day.
Vertical:
The perfect story goes from pixels to bits and back again. It goes through every layer and it comes out again. This criterion introduces one of those definition wars. I’ll try to be concrete, and let the lawyers work it all out later in court.
What we don’t want: the X layer is perfect, but none of the other layers work at all. Some typical values of X: The UI. The database. The service. The distributor. The CSV parsing. The PDF printing. The actual email.
What we do want: the story runs through every horizontal layer. It’s in the UI, it hits the service, it distributes to the handler, it parses the CSV, it changes the database, it prints the PDF, it sends the mail, it updates the UI accordingly.
So. The criteria we got for the perfect story to code starting today: Size, Shippability, User-Value, Plannability, Verticality.
Phew. I’m tired. Are you tired? I’m tired.
Clearly, finding stories that are perfect is not gonna be easy. We might have to slip not just one but several of these criteria. To do that, we should sort them.
So here’s the stunning climax, then I’m gonna go back to the dayjob, and I’ll elaborate a little more later on.
I sort story-for-coding criteria from most to least important like this:
Shippability, Verticality, Size, User-Value, and Plannability, in that order.
When I step back from perfection, the first thing I cheat on is Plannability. The last thing I cheat on is Verticality.
I have dayjob stuff to do, and a trip to take tomorrow, so you may not get the explanation right away. But I’ll get to it.
Have a cozy little Monday afternoon!