Estimation is one of the topics I receive the most questions on from Scrum professionals of all experience levels. It’s such a popular topic that all of our trainers have written blog posts on our website about estimation topics including discussions of actuals vs. estimates, estimation games, release planning estimates, and many others (scroll down and check them out or email me and I’ll send them to you!).
I’m neither a release planning expert nor an estimation expert, but I do get to talk to a large volume of customers about their challenges, so I’d like to share my perspective on it. What I’ve found through hundreds of conversations with customers is that the estimation challenge most folks think they’re facing is not usually the problem they’re actually up against. The questions are varied:
- Our estimations are often off and we’ve failed a few sprints. How can we estimate more accurately?
- Our stakeholders need to know when we can be done with feature X, but Scrum doesn’t tell me how to estimate. I’m the ScrumMaster and I don’t know what to do.
- The product burndown chart looks funny. I think it has something to do with our estimations being off.
When I hear these stories, I immediately start thinking about story writing, doneness criteria, release planning, velocity, team stability and misuse of tools. Then I remember back to college when all of my friends were EECS majors and how my liberal arts brain could often solve their problems by asking, “Did you try turning it off and turning it back on again?” Sometimes the simplest things can solve the most complex problems or at least get you unstuck a bit. I then ask one all-important question:
Where do your estimations come from?
Lo and behold, a large percentage of the time I hear answers like the Product Owner, a program manager, a business analyst, an architect, or someone else that doesn’t actually do the work is generating these estimations. “But how can I ask my team to look at all of the stories and estimate them? They need to be working!” I guess the answer depends on how important having best-possible estimates is to your organization. If it’s very important, the people actually doing the work should be doing the estimates.
The answer to estimation challenges, like most challenges in Scrum, can be found by going back to the basic principles of Scrum: empiricism and self-organization. First, by relying on empiricism, we know that our estimates are done by the actual team and are based on their domain knowledge and actual experiences doing similar work. We believe that since the folks doing the work—developers, QA engineers, UI designers, and other team members—have experience in the real world solving software problems, they are probably better suited than any manager to estimate the complexity and required effort of problems. Second, by relying on self-organization, the team will work together to negotiate its opinions on complexity and required effort to come up with a unified opinion of how difficult a problem is, providing a better estimate than could be otherwise derived by less-involved parties.
What is behind the drive to estimate work for the team by an outsider? First, it’s habit. Managers have been doing estimates for their team for years and they’re used to doing it. The team is used to having it done for them and may be so accustomed to not participating that they are unenthusiastic about having to estimate at first. Secondly, there is fear. For project managers who have authoritatively estimated work for their teams, giving that task back to the team can feel demoralizing. What does a project manager do once he or she is not managing everybody anymore? What do you do when the process your organization has committed to (Scrum) says you are no longer responsible for estimation and commitment? If your job as a manager within your organization is to drive the delivery of high quality software that sells, the only choice is to let the team self-manage while you lead. How to do that is another article altogether…
So whatever your estimation challenge is, before getting to tactics (and we do have many best practices for tactics), first make sure the driving forces behind the process are based in empiricism and self-organization. Let the team with experience doing the actual work, develop the estimates.
Download the PDF version: Estimate by Proxy Not in Scrum_blog