Thread by @GeePawHill

TDD Pro-Tip: The step-wise technique has to account for what the user experiences when, so I have to build ways to control that when stories get bigger than a day.

(A new friend asked the question: when stories get hefty, how do we "live at HEAD" without exposing our users to code that's still WIP.)

First the one-liner: don't do that. Don't work on stories that are bigger than a day.

What I mean is, there's a cost to controlling user-access to code. If I can write stories so they all take less than a day, I *never* have to pay that cost.

The fallback position is: no, seriously, don't do that. I ask myself have I really *tried* to split the work a different way so that each element adds value for the user and fits in less than a day?

My experience in the field, spread far and wide among perhaps a gross of teams just approaching agility, is that most teams spend on the order of 0.01% of their effort trying to split.

They glance at a story, they think to themselves "a week", they give whatever bullshit story-point number they think corresponds to that, and we all thank god another meeting is out of the way.

The arguments in favor of "call it a week and move on" are generally these: 1) it's just a week. 2) the customer won't accept it unless it does all of this. 3) we have to cross team boundaries to get it done, and a week is optimistic anyway.

1) Humans suck at estimates in complex systems, but estimate-suckage isn't linear. The bigger the estimate, not just the bigger the error, the bigger-*er* the error. Quick like a bunny, one day turns into a day and a half, and one week turns into three weeks.

2) That the customer won't say it's done until she's happy with it is certainly true. But it's irrelevant. We could say the same thing about the whole app, but we don't: we split it into stories. To get this, you have to understand what stories are doing for the makers.

The makers, remember that includes the people on your team who describe the product they want, use stories to narrow the mental bandwidth required for their work. That's what stories are: purposeful narrowings of bandwidth.

This customer-developer split is one of the ways our movement has gone wrong. Stories aren't "for" the customer and they aren't "for" the developer. They are "for" the makers, which group includes both.

3) Cross-team boundaries slow everything in the entire universe down, beyond any ready belief. Absolutely true. The deep fix to this problem is out of scope. There's a shallow fix, but it's hard enough.

The shallow fix. Stop everything. Create a temporary SWAT team with folks from both teams. Tell them their day job, their *day* *job*, is to solve this problem. But don't just send them to their keyboards: have them start by splitting it into one-day stories.

So, to reiterate my starting position: don't do that. Don't take on stories bigger than a day. And my fallback position: don't do that. Don't take on stories bigger than a day.

Now we're left, though, with two questions.

1) What are the clever ways to split things we're just not thinking of?

2) How do we control access to WIP code if we really really tried really really hard to split it but we can't pull it off?

(Apologies for the deleted tweets. Saying "week" instead of "day" was too big a word-o to let stand.)

<Sigh> That's two more muses, and for crying out loud it's Sunday afternoon.

Okay, I guess I'm still feeling fresh enough. Gimme an hour, and I'll do the next one. Not committing yet to which of those two questions we'll broach next.

Anyway. stay tuned, I'll be back!