Once (ok, let’s be honest, not just once) I was thinking, “Why not to get rid of estimations?”. I heard a lot from the developers in our company that they hate estimating. That is usually a very painful process for a project manager, too. Not only because of the process itself, but because of what happens afterwards. If you worked on more than one project, you definitely know that the estimation your team created won’t be ok for business people. They certainly know that this feature is very easy and that story can be done in a day… Or, “My colleague – he is a developer himself – thinks this can be done in a week!”. They all need hours, exact numbers and deadlines. Team wishes not to provide that.
Why we can’t get rid of estimations
Estimation process is not about providing the number of hours team would spend on certain task. Team can spend 4 hours discussing a pack of backlog stories and only 30 minutes on estimating them using planning poker or size markers. The main thing that happens during the estimation process is the development of common understanding of an issue/story. We discuss details, clarify the vision of the architecture or some business logic and build the “model” that is visible for the whole team. Only after that we can come up with some numbers.
If the team skips the stage of getting that shared understanding – they will definitely face it during the sprint/development. If the team is not going deep into details, they will have too much discovery going on during the sprint: unanticipated work, missed deadlines/deliverables.
The other big problem can be the technical debt – team should have the clear vision of how big is the tech debt and what is the code quality. Let’s imagine the team is not familiar with the code base at all – it results in making commitments without clear understanding of what work actually needs to be done.
Two worlds
Our customers definitely need estimation. How can they plan if they don’t know when the work could be done and how much it would cost? They push the teams to provide the estimations in hours so that they can count the costs.
Developers hate estimation in hours, as they usually fail in giving the right numbers. Ok, as a project manager, I double their estimation before providing it to the customer. But it is still not enough sometimes and does not add any transparency to the process.
But I found out a surprising thing – customers don’t really care about the hours, as their final goal is to get costs and timing. If you provide them cost and timing, they don’t care how you estimate – in store points, hours or bananas. They would bless you if you could provide them an up to date information, as backlog changes often.
What I hate about estimations
So, I found out that I am not against estimation and understand why we need that. But what does make me crazy when it comes to estimating?
- When you are asked to provide the estimation for a new big project in 2-3 hours. “Really, I know that it would be a rough one, just give me the numbers. I would warn them it is a rough number, just your thoughts on the project length.” And then you get the contract signed with this number. There is no way your team fits into this estimation, but it is YOU who provided the numbers… So, nobody to blame except yourself.
- When you are told, “This estimation is too high. No, we don’t want to change the scope. You should find ways to do is faster.” I Especially like to hear this phrase from the sales people. Our team estimated this backlog and they will do this work. That is the way and speed they work, I can’t make them “twice faster”! I know that they do their best and there are definitely teams out there who work better and faster. You don’t like the team? Change the team!
- When someone else estimates the backlog for you. You get a signed contract. No comments.
- When sales people divide the estimation by N, because it is easier to sell this number. Why do that? When I get such case I know that we won’t fit into the budget. My team is not stupid, too – they see that they won’t fit into the budget. Usually I get some valuable advice from the sales person, like “But you are a professional… Fit somehow! Cut the functionality the way client won’t notice…” *sarcasm* Just imagine – in the beginning of the project the whole team understands the project will fail! How great would be their work? Should we expect to have problems in half a year, when client realizes we are 3 times over the budget? In all such cases I re-estimated the backlog with team and provided my client the real estimation – in the beginning, not in 6 months. And we survived that. Though every time it was a battle, where a sales person of your company is not on your side.
Try to avoid these 🙂
Nothing wrong with estimates, but measurements should confirm or refute if your estimates were valid. We have to start somewhere, might as well take a stab at it. Proportional estimating seems to have a reasonable track record – aka planning poker and it is more efficient than Wide Band Delphi technique, both of which I have used with some success.
I have referenced your blog (made a link to it) in my blog post on Monday morning 0800 east coast time. I think, if it is okay with you, that I will point to your blog when I see things interesting. This gives us a chance for collaboration
Hi! I am very glad you are interested in my blog. Do not hesitate linking/reposting! Thanks!
Thank you – I referenced you blog – pointed to it in my post, and posted it on LinkedIn and my groups. Perhaps we can help build a web of interesting blogs pointing to posts we think our readers would like