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.
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.
(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!