In every iteration, we make a commitment. Commitment is a scary word, and it should be. Estimation in the development world is the Devil. I've found that my initial estimates are normally off between a factor of three and five! When you make a commitment, you're saying you're willing to do what it takes to achieve the commitment. This means working longer hours, slacking a little in the test department, and foregoing elegant code in favor of what works for now. Obviously, you don't want to overwork yourself, leave your code untested, and leave an unmanageable mess behind - so you don't want to over-commit. However, we have to be competitive and useful as software developers. The game is like Black Jack - don't go over, but get as close as you can to 21. In our case, we want our commitment to be backed by an accurate and reasonable estimate.
There's lots of things that can influence an estimate, and all kinds of tricks you can use to break down the work into estimable chunks - all of which I won't cover. What sticks out to me is how unknowns are dealt with. If I were to ask you how long it would take to haul good between Kingman and Golden Valley without knowing anything about the two towns, you might be able to SWAG it, or put some silly upper limit on the estimate (such as saying that can air-ship anything to anywhere in only 7 days - or something). Then you find out that Kingman is on Earth, and Golden Valley is located in a fantasy realm called Xanastan, and to get there you must commune for twelve hours and then spill your blood into the pools of Estertide. While this is probably the worst possible example I could come up with, we get burned by this constantly as software developers.
The answer to all of this is that you don't commit to any unknowns. When you're talking to your customer, and they ask you how long this odd thing will take, tell them that you'll get back to them. Make a research task for it and limit the amount of time you'll spend on it. This time isn't typically billable of course; after all, you're a highly paid and professional software developer. Once you've created your prototype or done your research, you should then be able to make a somewhat accurate estimate. At the very least, you can commit to something.
2 comments:
Great post.
Too often when I first see acceptance criteria, I'm sitting in the middle of a planning meeting with the client checking their watch. I check the estimate, I make a commitment, and lo and behold I'm up until 1 AM coding to meet a deadline, my wife is angry, and my kids are neglected. All because I missed that whole new feature that was lurking in the A.C.
So to the above I'd add the advice to get your acceptance criteria while you can still take the time to get a good, hard look at them.
Post a Comment