Estimates are supposed to represent some value of complexity for the simplest possible solution for what gives value to the client. It's not a representation of hours, but just an idea that task X is about twice as hard as task Y. Developers are typically very bad about estimating hours, and need to pad those estimates by factors of 3-5 if they don't want to eat the cost of estimates. Since we bill hourly, and not per point, there's a disconnect. You can start getting a rough idea of a points per hour ratio once you've completed some work.
Unfortunately, we get hung up on some things with estimation:
1) Simplest Possible Solution - All login stories are a 1. This is because I can implement login by dropping a .htaccess file in the proper location and now my site has login. I didn't have to create a user table with a user model, and a controller to allow login, or any of that fancy stuff. Why are you overcomplicating such a simple implementation? Because that's not what clients need in most applications. Remember that the simplest possible solution is the in context of what delivers actual value for that app. Facebook can't use a .htaccess file for login, but some apps might (as we have implemented before).
2) Re-estimation - Estimates are a hunch of the complexity required to complete a task. Estimations reflect how complex a story should be, not how complex a story was. They are not historical indicators. If a client loads up a story with acceptance criteria that makes it worthy of a new story, you must commit to less work, and inform your client that this will have an impact on delivering good software. This means you talk money. You let him know this is going to cost him. Go ahead. Rub your fingers together. Smile big like you're about to cash in. When you start throwing around how many Earth Dollars that Ajaxy spinner stuff is going to cost him, you've forced a decision on them. They must choose to pay more, remove the silly things they are adding, or remove some other feature. This decision is far above the pay grade of mere mortals such as you and I, and it means that we can't be wrong. If they torpedo a project despite our advice, it was done with their hands, not ours. My experience is that this doesn't happen in the real world. The system is far too organic to fail if both the developer and the client are having active discussion on a daily basis on how to cultivate an application into a valuable product.
3) Estimated velocity - Velocity is the rate of stories being completed. This is a target, not a requirement. Our commitment we make (which we try to push to be at or above the target), is the requirement. Don't kill yourself to make this velocity. Developers don't go into an application. Applications come out of them. Instead, commit to less. Project to the client what that means and how that effects the project. You might be able to pick it up next week if you feel you have some hard stories ahead of you, and it's unavoidable. You can also use it as a mechanism to show how their constant stacking of extra little things is adding up, and sinking their project.
4) Including Design/Testing - Shame on you. All stories include design and testing. If you think a story is going to be more difficult to test than a normal story, bump it up. If it's going to be harder to design than a normal story, bump it up. When a story is done, that means you can walk away from it and pretend it never existed. You don't deliver stories without any design. That's unprofessional. That's what the high school student working for sweat equity does. Not you and me. And testing? It doesn't make writing a method faster, or assigning a variable faster. Increases the speed of developing features. So when you cry to me and say that we didn't include testing in the estimation, you are telling me that you are a bad developer asking for regressions. There, I said it. If you aren't testing because it slows you down, then you have something very fundamental to learn as a software developer. This is like you telling me that you don't understand inheritance, or the difference between an object and a class. There's loads of materials on testing, and even folks like me that are eager to help you. You get free executable documentation for yourself when you get code rot, and others when they jump into your project blind to help you out. You have a safe place for refactoring when you need to make changes, and mitigates regressions. If testing seems hard or time consuming, you might look replacing your testing tools with better versions that get the job done for you.
Despite all of my rant, and the rants others have made on estimates, they are just a guess that's turned into a metric. They aren't a big deal, and being a little off isn't a problem. If your estimation sessions are taking more than 15 minutes, you're taking it too seriously.
2 comments:
Repeated use of the term "story" made me giggle.
Good, useful information here. Don't sell yourself short with the "pay grade" talk...it's ultimately the client's decision, but in my experience a client likes as much input as possible from the developer. Yes, they (hopefully) know the app requirements and user expectations, but as a developer you've likely been down a similar road before...it rarely hurts to give your input - assuming you have a client that's interested in hearing it.
Post a Comment