I have just come out of a planning meeting that I thought was a complete waste of time. We spent a full hour trying to estimate roughly how many days a number of user stories take and comparing the total to capacity days in order to work out what we can commit to in this sprint. Bearing in mind that these stories were already estimated in complexity points. Not only were we doubling the effort, but we were needlessly prolonging a meeting to reach an agreement on commitment based on inaccurate data.
I am not a fan of estimation in general and time based estimations in particular. I have seen it been abused so many times that I no longer think it should be used. Additionally, estimations are just that, an estimation - a guess based on what you know about the user story at the time of planning/grooming, which is, most of the time, not much at all. The only exception is when you are estimating a piece of work that is similar to something you have already done before but that, in my experience, is very rare. Mostly when I raise this concern, I get the “let’s get better at estimation then, shall we?” Why? surely that time is better off spent delivering value to customers. And what better way is there to delivering value than working software?
Estimates can be used to drive discussion during planning, especially when team members have big differences in their estimations. But do they need to be kept after that? Where they are truely useful is when they are used in conjunction with business value for prioritisation. To allow the product champion to target items that have higher business value but low complexity. This will ensure we are delivering the maximum value in the shortest possible time, in theory at least. But in these cases, all you need to know is roughly how stories compare in terms of complexity. T-Shirt sizes are sufficient for that and there is no need to get into academic discussions to determine whether a particular story is a 1 or a 3.
If we are not estimating, then how can we determine when a project can be completed? How do we measure velocity to determine what will be delivered when? Stakeholders will never agree to a “we will be done when we are done”. They need milestones, deadlines, commitment. How can we put their mind at ease without estimations and planning? This will be the topic of my next post.