How To Do Agile Estimation The Right Way
As organizations and teams mature their agile practices they are often faced with new questions. Leaders might ask, “Can you tell me when the feature we prioritized will be done,” or “Can you share with me a list of features that are likely to be done over the next few months?” A product owner might ask, “How expensive and complex is this enhancement,” and the operations team might want to know, “Can you squeeze in these defect fixes in the next sprint?” … Many agile tools measure team velocity, or how much teams can get done in a sprint, and teams will want to define, measure, stabilize, and ideally increase their velocity. More advanced teams often want to look at their overall performance across many sprints: Are they delivering higher quality when they work on lots of small stories, or just a few big ones? … Agile estimation requires you to come up with a methodology on how a team should develop consensus on the estimate. You might hear about planning poker, the bucket system, affinity mapping, and other estimation techniques. In my work, I usually empower teams to decide how they will work together to come up with their estimates, but I do provide some guidelines. Estimates should reflect on the effort and complexity of the issue being worked on and should account for everyone’s work. InfoWorld, August 29, 2018, How to do agile estimation the right way. Image: Black Pepper Software Limited
As organizations and teams mature their agile practices they are often faced with new questions. Leaders might ask, “Can you tell me when the feature we prioritized will be done,” or “Can you share with me a list of features that are likely to be done over the next few months?” A product owner might ask, “How expensive and complex is this enhancement,” and the operations team might want to know, “Can you squeeze in these defect fixes in the next sprint?” … Many agile tools measure team velocity, or how much teams can get done in a sprint, and teams will want to define, measure, stabilize, and ideally increase their velocity. More advanced teams often want to look at their overall performance across many sprints: Are they delivering higher quality when they work on lots of small stories, or just a few big ones? … Agile estimation requires you to come up with a methodology on how a team should develop consensus on the estimate. You might hear about planning poker, the bucket system, affinity mapping, and other estimation techniques. In my work, I usually empower teams to decide how they will work together to come up with their estimates, but I do provide some guidelines. Estimates should reflect on the effort and complexity of the issue being worked on and should account for everyone’s work. InfoWorld, August 29, 2018, How to do agile estimation the right way. Image: Black Pepper Software LimitedWhat made me fall in love with Scrum was … velocity. Someone was using objective data to see how well they were performing. Perfect, I thought. Someone finally accepted that complex methods rarely meet, let alone exceed, simple numbers such as averages, and then they put that into a cogent software development method. Maybe an agile approach is OK after all, I recall thinking, except for that pair programming thing.
So then, what happens when we need to estimate the overall effort? Estimate a whole bunch of Scrum sprints needed to get a product out the door? I kept looking for the recommended method but never saw anything that looked different than the classic approach of getting people together and deciding based upon their individual work estimates. Ugh. Certainly, that hadn’t worked well in the past, at least nowhere I had developed, managed, or researched.
What had worked for us? Velocity, or better stated, the methodology behind velocity, the average. It always drove people crazy that I’d advocate averages or simply use averages on my projects. The first sign that the averages were better than the complex Monte Carlo, regression-lined, dynamically programmed, and “wisdom of the crowds” estimates was that they were always longer than the duration produced by these more complex methods. The other notable characteristic of the average was that it was always right in the middle of how long it actually took us to complete our last projects. Why that would surprise anyone was always a mystery to me. Especially since we had consistently missed our delivery dates by 20-50%.
When I saw this article’s title, I happily clicked on it looking to see how someone had probably shown how to use a velocity type measurement for the project as a whole and how they had improved their estimating and now they were consistently hitting their deadlines. Nope. Instead, it looked like the classic “try these things, I’m sure they’ll work,” along with no mention of how they had worked for the author.
Compare with “Let’s try this” is not a metrics plan
When management or experts would argue that the average was too simple, I would suggest that they use their desired method and also compute the average, and then track both of these estimates together. It would be hardly any effort to do that, but it was amazing how often — just about always — that the reaction was that they were not going to do that. One would think they would want to do that to show me up and shut me up, but no one ever took that opportunity.
See also Is your estimation on steroids? and Your average is powerful!
Are your other project estimations as objectively based as your Scrum sprint velocity?