Stop Estimating - Start Projecting With 1-Day Stories
I've been having discussions with some folks about the best way to solve estimation and commitment problems inside of a Scrum team.
To me, these are the same problem. If you didn't estimate work, you couldn't "commit" to it.
Also to me, estimation is a form of waste. Lots of people agree with that, calling it a necessary waste - something that you had to do so that people would know when to expect something to be done. And then the team "commits" to that estimate.
So how is that an estimate? An estimate is actually an unnecessary waste - we don't need to do it, we just aren't aware of or comfortable with another way to do it. It's the way it's always been done.
Here's an example of a conversation I had recently. This example benefits from "wow, it would have been cool if I had said such and such" style hindsight in a few places. :)
So what's your big alternative to estimation?
Project a delivery date based on actual work that has been done and then do some math (extrapolate).
But how can that work? User stories aren't the same size!
But what if they are? What if they are all 1 point (or 1 day) stories?
But they aren't!
Okay, agreed. But what if we treat them like they are?
Well, we'd be screwed pretty quickly!
Initially, yes. But then, what if we did retrospectives on stories that were differently-sized?
Huh? Why would we do that?
Because, if we could learn how to break up stories to make them all pretty much about the same size, and we knew how many we could do each day, wouldn't we be able to calculate (project) a completion date?
Well, yes. But some stories are huge and others are tiny.
OK, agreed. But isn't it true that it's only the bigger stories that are a problem from a delivery standpoint? Smaller stories will get done faster, and we'll finish faster. It's the "over-sized" stories that can (and will) derail us.
Well, that's true. But what do we do about them? Isn't every story supposed to deliver some value to the customer?
Yes, I've heard that. What if that's not the best way to define a story?
Uh... okay...
What I mean is, I have learned not to be dogmatic about process. And I think the customer is mainly concerned that if we tell her that she will have her new release out the door on December 15, that's what happens. I doubt we'll get lots of excitement about how every single story we completed delivered some value, but the release date was still missed.
Yes, I'll definitely agree with that. So what do we do with these big stories?
What I've been toying with for the past year is treating these as work orders (remember that old phrase?), not stories. Then we break down the order into line items, and no line items is allowed to be more than 1 point. Once you complete the work on the last line item, your work order is ready to ship. Meantime, all of the smaller orders (one line item each) just get moved through the "fulfillment" (development) process.
I see how that might work. And the team is deciding what is a 1-point story and what is a larger order that needs to be broken up?
Yes.
Well, that doesn't really sound that different from estimation. You're just as likely to be wrong about what is a 1-point story as opposed to a 10-point story.
It's true that we'll make mistakes, and something that looked like a 1-point story (I really call them 1-day stories) will get into a sprint and it will gum up the works. But we'll know about it on the very day that it was allowed to start up - because it's a 1-day story. If it didn't get to the end of the line (ready for deployment) by the end of the day, then it wasn't a one-point story.
Then what?
Several things happen next. First, the line stops and the team must do an immediate root-cause analysis on what is too big about the story. Once we agree on what the problem with that story is, the story gets ejected from active development and the fitness criteria for stories is updated. A replacement story is slid into its place and work resumes.
Wait - fitness criteria?
Yes, the team maintains a set of characteristics that stories must have in order to advance from one stage of development to the next. If a story doesn't meet the criteria, then that story is really a larger work order and has to be broken down.
What are the fitness criteria?
It varies from team to team, but some of them are the basic things that you probably have in the back of your mind: there must be acceptance tests, there must be unit tests, any third party documentation needs to be supplied, any open questions must be answered.
Sounds like pretty obvious stuff.
But team-specific criteria will surface over time. For instance, on my current project, a story can only span one tier of the application. So you can have a story about login page, but it can only consume a fake DTO. There must be another story for the service implementation, and a third for the entity/database work. that's because that team has decided that they can move fastest when focusing on only one tier at a time. Other teams might not have those criteria because they work together a different way and that would just slow them down. And over time, this team might improve their capabilities and relax or remove those criteria. But the criteria exist to keep work that is too big from gumming up the works.
A lot of this sounds like stuff that professionals should just do as part of their work.
In theory I agree. However, if that were true, then no surgical implements would ever be left inside of patients. But they do. And no airline pilot would ever show up to work drunk. But these things do happen, and to control for these variables, people have come up with checklists to ensure that all of the i's are dotted and t's are crossed. That's all this is. And it gives us the added benefit of being able to project a delivery date as opposed to, essentially, guessing.
Wow, you're awesome!
Aw, shucks. *blushes*
Okay, so I made up that last part of the exchange! In actuality, mostly these discussions end with the other party still being curious but highly skeptical that it would work for them. And I get that. I have only been able to have this sort of experience working in a very small team for a very agreeable entrepreneur. I would not have been able to run this test very easily at my more recent companies.
However, I would highly recommend at least skunks-working this as a test inside your own teams if at all possible. I'd be happy to help stand up an experiment with you if you like. Just let me know!
Also, please post a comment and let me know what your impressions are. Much appreciated!
