I ended up in a twitter conversation last weekend about estimation and velocity. It started when Annu Augustine asked about what qualities to look for in a lead developer, other than technical skills. One of the qualities I put forward was accurate estimations. This went around a bit and ended up, not surprisingly for me, at velocity. There are a couple of points that I need to offer my opinion on:
I ended up in a twitter conversation last weekend about estimation and velocity. It started when Annu Augustine asked about what qualities to look for in a lead developer, other than technical skills. One of the qualities I put forward was accurate estimations. This went around a bit and ended up, not surprisingly for me, at velocity. There are a couple of points that I need to offer my opinion on:
Accurate estimation is not an oxymoron. Let’s just get over some technicalities first: “accurate” is not the same as “exact”. Estimation in software is never exact, but the magnitude of accuracy is very significant. If I say that something will take approximately 2 weeks to achieve, then I need to qualify “approximately”. What is the magnitude hidden behind “approximately”? Is it 10% accurate, 50% accurate, 80% accurate? Let’s say it is 50% accurate. This means that I can finish this work at best in 1 week or worst 3 weeks. That’s a big swing. As a good developer, it has to be better than 50%. If it’s 50% or less, then it is an indicator that you are lacking understanding (i.e. knowledge) in a key part of the problem and/or solution domain. Then you have to estimate on what it will take to overcome that ignorance, before committing to the original request.
An estimate is not a commitment. If you mix these two concepts together, then you most likely will be in trouble sooner than later. The estimate is based on something that you understand and that you can foresee with good accuracy. In other words, an estimate is a prediction of the future. The commitment is a promise that you make on part of the estimate in order to make that prediction come true. If I predict that a problem can be solved in 3 days, then I may make a promise for some part of it by the end of the first day. This distinction may surprise some who have been using the poker game, or other estimation technique in Scrum. Scrum teams use estimates in planning make commitments for the entire sprint, then track and calibrate velocity via burndowns, which leads me to the next point.
Team velocity or relative estimation does not make for better estimation. Knowing what a team’s velocity is based on tracking historical trends is only a measure of the energy the team has expended to date. This expended energy (the area under the curve) is used to predict the potential energy of a team. That’s all, nothing more nor less. I will stick my neck out and go so far as to say that relative estimation in points is not at all about estimating, but a way to accurately predict the potential energy of a team. I’ll go even further: relative sizing does not work because software development is about crunching new knowledge, and every new piece of work should be crunching more knowledge. If it’s the same thing over again, then the design is flawed or at least at the wrong level of abstraction. Jumping levels of abstraction, and re-shaping designs takes quite a lot of knowledge crunching and is not relative to anything else but your existing knowledge. So, relative estimation does not make for better estimations and velocity just tells you the potential energy of the team.
Where does this leave me? I’ve given up on relative sizing and estimation. Knowing my own velocity has not added any value to my ability to estimate because every problem is unique in some way. I estimate based on the knowledge that I have at that point in time, and force myself to be aware of my accuracy. All of this, and more, has made me appreciate the value of one piece flow a lot more than time boxed flow.
f3yourmind 
Story points are great on a product backlog for roughly putting similar sized tasks into buckets (all those tasks are a 3, those are 8’s etc).
However, I really dislike using story points for sprint commitments, because they aren’t mathematically consistent. For example, teams commonly use 3,5,8,13 etc as points. Whatever 5 means to your team, 8 probably means twice the time/complexity. Now assume a team has an average velocity of 15 points.
Mathematically, we are saying that the team can commit to 3 tasks of 5, or 2 tasks of 8 (approx). But 8 is already double the time of 5, so 2 of 8 is really 4 of 5. How is this the same commitment?
I agree with you regarding the value of estimation, but I believe that it needs to turn back into a number that has meaning, not just a story point. The fallacy is basically that you can add up story points – I don’t believe you can.
Yes, it is meaningless because it’s based on fibonacci sequences and the characteristic of the sequence is that fib(n+1)/fib(n) converges to 1.61803399. So, every point value is about 1.6 times the previous point value; i.e. a 21 is 1.6 times a 13, 13 is 1.6 times an 8. However, we measure time on linear scale which results in this confusion.
I do agree that building a histogram of estimates (and it does not have to be points) is useful to get the shape of your backlog because that shows you how much you know and how much you don’t know. I explained that here http://aslamkhan.net/software-development/whats-the-point-in-scrum/
AslamI agree with you. For me as a product owner, I understand that estimates are based on what a developer knows at a point in time. It is also important for a product owner to be very aware of the accuracy of the estimation. The most important thing for me is communication, when a developer has a better understanding of the problem and the estimation accuracy changes, this needs to be communicated. Software development is a complex beast and to view an estimate as a commitment is questionable.