Recent impromptu meetings with the software team about our existing development process had me re-think my thoughts about our way of estimating user stories and tasks. Personally, over the many months, I’ve grown to dislike estimation of user stories by complexity points and tasks by man-hours for two reasons: one, sprint planning sessions take too long and boring because of them, and two, they do not help the team develop better software. They actually delay us a bit, because we can’t start right away. I’ve recently wanted to completely remove the practice because of those grounds.
I vividly remember Gojko Adzic making a point in one blog post about burn-down charts and velocity being negative metrics (like high-blood pressure) and bewaring us about using it for measuring software development success. I also clearly remember Ron Jeffries talking about estimation as being evil in an article. If I’m solely looking at the ideas pointed out by these two intellectual minds in these posts, I don’t see why we should keep doing them.
Ron, in another article about estimation (two months after his ‘Estimation is Evil’ post) gives me one compelling reason: responsibility. He tells me that it is the team’s responsibility to guide the project well in all the ways we can, including estimation. He tells me that our stakeholders are asking us for help about a business decision and it is important that we provide them with the best educated guess we can spare. Okay, that was a wonderful counter-argument.
So, we keep estimating. But we must find ways of doing it that helps both the stakeholders and ourselves. If the idea of estimation is not the problem, maybe it is the way we estimate that’s annoying us. Maybe it’s because we estimate by points, by man-hours, by numbers. Maybe it’s because daily re-estimations distracts the team from simply doing the work. Maybe simplifying how we estimate, by using non-numeric estimates (to speed up the process) and by providing an estimated timeline (which might be what they really want to see) instead of documenting day-to-day computed numeric estimates, is what the team needs to do.