We were taught, ages ago, to write User Stories so that they made business sense: As a [role], I want [some ability], so that I can [accomplish something valuable].

These days, we realize that’s not really ideal – at least not for the small things we chunk our work into, and commit to delivering for an iteration or sprint.

Features, Epics, Value Stories – those big things that you can only deliver a few of per Release – THOSE things must make business sense at a course level of granularity. For those, the old recipe still makes sense: As a [role], I want [some ability], so that I can [accomplish something valuable].

Indeed, for those bigger features, you should frequently know how much money you will save, make, or at least not lose as a result of implementing it.

But pity the poor team! The team that commits to delivering a certain number of chunks of useful work per Sprint or Iteration! For purposes of getting them into a steady, even flow of delivery of those chunks, the thing that seems to matter most is this:

Those chunks of work are all about the same size, and that size is really, really small.

Think of it this way: an entire Release MUST deliver Features with business value, and…

…an entire Sprint MAY deliver an entire Feature with business value…

…but from day to day, in the heat of software battle, you really just want the delivery of chunks of valuable work to KEEP ON FLOWING.

If your smallest story requires two days to complete, that’s going to get you in trouble.

If the average ratio of smallest to biggest stories is something like 10 to 1, you’re gonna get into way MORE trouble. You’ll blow your Sprints, and likely your Releases too, and meanwhile your code won’t be getting any healthier under all of that constant emergency pressure.

So, presuming you have defined some Features you need to get done, that have been described using the old user story semantics (and that have acceptance criteria, and perhaps a Gherkin semantics for that, and perhaps sample data, and perhaps dollar values):

Divide them! Divide them into things, and divide those things into smaller things, and keep dividing until you need a microscope to see them. You may not need super-fine granularity for every such chunk of work every time, just as you might not need every Java method to be less than 15 lines of code. But you DO need to know HOW to make chunks of work super, extra, pico small.

Now give each of those little bitty things decent acceptance criteria and, if necessary, sub-tasks. Only once you get to that point, and stay there for an entire Release, will your work truly have that steady, comfortable, humming flow of continuous production and improvement. Only then will your team and management begin to outgrow their addiction to last-minute-emergency, and over-committing, and last minute death-march, and integrating too late, and dividing things up too late.

Small is the New Big. Truly.

Maybe they are not even user stories any more. I don’t know. But whatever the heck they are, they are really, really, really small.