i've had some questions & comments about yesterday's tweet:
that's natural and good and thanks to one and all. when one tweets a one-off like that, all pithy and telegraphic, folks who may not "already speak the lingo" can be mystified. i'll take a few tweets to spell it out a little further.
a little about the context. in the modern synthesis, i speak of four optimizations we want to attend to in writing software for money. we optimize for collaboration, for sustenance, for drive, and for stepping & mis-stepping.
optimizing for sustenance is the most relevant for the story-slicing tweet, so let's go there.
optimizing for sustenance is about building our software in such a way that we are able to feed ourselves sustainably as we go. it is the continuous ongoing reaping of the value that our software adds to the world.
there are good reasons to set the "journey" metaphor aside, but it's still commonplace, so... optimizing for sustenance means gathering food and fuel *as* *we* *go*. this opposes the older style, where we build software to reap its value only at the "end" of the journey.
user stories are one solid mechanism for getting us and keeping us in this mode or frame. they describe some aspect of what we're wanting to build, focusing their attention on who it's for and why they want it.
user stories then help us organize what we work on, and -- user stories are always applied in time -- when we work on it.
this "in time" aspect creates great confusion for noobs, but it's a critical factor in their usefulness and in the modern synthesis outlook.
when one first comes to stories, one is often coming from the world of a requirements document. requirements documents are *not* "in time", but "once and for all". they are not built for "feed & fuel as you go", but for "feed & fuel provided upfront and recouped at the very end."
so. we use stories to organize what we do and when. but we're not done nailing down stories just yet. why not? optimizing sustenance is an intricate calculus involving cost & benefit & all the other optimizations. a central number in that calculus: "how big is a story?"
to get this theory into actual motion, we need that calculus, and we're going to have understandings about the size of a story.
how big is a user story? how much work is in the typical one? how much work is in the biggest story we'll call legit?
how big is a user story? how much work is in the typical one? how much work is in the biggest story we'll call legit?
twenty years into this, and we've tried a ton of different ways to specify the answer to this question. i would like to tell you there is a consensus answer, but i can't. all i can tell you is that there is a consensus answer among the people whose advice i trust the most.
how big is a story? in my circle, we seek to create stories that take "about a day or two in theory".
i know, i know. there's a lotta fuzzy pulp in that juice.
i know, i know. there's a lotta fuzzy pulp in that juice.
it comes down to this, whatever else we've learned, we've learned that smaller stories are better. they are better for a bunch of reasons i'm not even gonna bother to go into today -- read my backline or ask me questions if you need more.
now, armed with all this, we're finally ready to think about story slicing. the problem is as simple and as hard as this: "we have a thing we think is a story, but no way can it fit into about a day or two in theory, so we need to slice it into smaller stories."
if a story is to be sliced, split into pieces, will any old pieces do? the answer is no, decidedly not, and my tweet yesterday was a short strike against the most common form of mistake in story-slicing: slicing by horizontal architectural layer.
say our story -- in many shops this would apply to 100% of our stories -- will require changing 1) the web pages, 2) the endpoints, 3) the access rules, 4) the controllers, 5) the rules engine, 6) the threading, and 7) the database.
easy, the noob says, we'll slice our story into 7 stories, one for each of those numbers above.
but that's not what an olb says. i'm an olb, and it's exactly the opposite of what i said yesterday.
but that's not what an olb says. i'm an olb, and it's exactly the opposite of what i said yesterday.
why not? (that kind of slicing is called horizontal or layered slicing, shorthand i'll keep using). what's wrong with layered slicing?
the problem is that a layered slicing, while keeping the part of our story that has to do with when and what, completely ignores the overarching justification for using stories in the first place: optimizing for sustenance.
when we slice a story, we are not trying to divide (or even optimize, we'll come to that) the *labor* that goes into it. we are trying to divide the *value* that comes out of it.
on paper, the value we receive at the end of an effort is always the same as the value we planned to get, and it's always the same as the sum of the efforts we put into it. this is idols of the schema with a vengeance: it is approximately never the case in business practice.
on paper, nothing ever changes during an effort. we encounter neither internal discoveries that make us want to shift our plan, nor external conditions that make us want to shift our priorities in the market. but in actual business practice, both events are ubiquitous.
and that is why we want to split stories in such a way that each story provides value, regardless of whether the as-yet-unstarted stories are ever chosen for implementation.
put another way: if we slice that story above into those seven layers, when can we walk away? when can we harvest whatever sustenance we get and move on to the next thing?
and the answer that kills that kind of slicing is: "when we have done all seven stories."
and the answer that kills that kind of slicing is: "when we have done all seven stories."
"when we have done all seven stories" is too late. we can't ignore internal discovery or external change for that long. we can't not harvest value for that long.
and thus my tweet. story slicing by horizontal architectural layers is a common mistake. it derives from mis-focused attempts at optimization, from misunderstanding what we're trying to divide, and from faux-rational arguments on paper that don't work in reality.
this is a long muse already, and i feel i have two other long ones aspawning: how, then, to slice? and why optimizing for business and optimizing for geek labor are often two different things. so let me wrap this one up.
we seek to optimize for sustenance, the ongoing partial harvest of value. we use stories -- descriptions of partial value -- to tell us what and when to work. we want them small. when we split them, the thing we're distributing across the splits is *value*.
and here's the blog for easier kvetching: "Slicing Stories? Don't Use Horizontal Layers" geepawhill.org/slicing-storie…
