Four sins to avoid in Agile estimating and planning

One of the most significant issues that I have faced in Agile coaching engagements has been with respect to making and fulfilling commitments. Estimates provide the basis / input for making commitments. If you have poor estimates, your problem in meeting commitments starts before you have even embarked on your product development.

I have found there are four major mistakes – I am calling them “sins” to amplify their importance – that organizations tend to make as part of estimation during planning at different levels.

1.Pushing for expectations and targets to become commitments

Product Engineering and Management organizations have an expectation / target for product releases from a market perspective. This is often pushed down into the development / scrum team for them to commit as part of product and sprint level goals. Realistic estimates from the scrum team could be very different from these expectations (invariably there is a large gap between the two). Teams are held accountable to expectations and targets whereas there is a need for a plan to bridge the gap between targets/expectations and the team’s realistic estimates (for example through a prioritized / reduced backlog, additional resources or other means that are negotiated between the team and the concerned stakeholders) as well as to help the team execute that plan.

2.Estimates driven by Product Management

This is an issue in many product organizations. While Product Owners are part of the scrum team, they need to respect the fact that estimates are to be done by the team responsible for delivery and neither the team’s management nor the product management should interfere in that process. This problem is more acute in companies where the Product Management team comprises technical people who believe they know what is involved in the development of the software, and as a result, what it takes to deliver. They end up being more active participants in estimation and start providing inputs to the team on what the estimate should be. They question the team’s estimates and end up influencing them. Such behavior will lead to unrealistic commitments and ultimately project failure.

3.Team delivering not involved in estimation

Initial estimates and commitments are typically made as part of release planning in a project. Subsequent commitments are made at an iteration level based on estimates done during the backlog refinement sessions and iteration planning. While the team is always involved in detailed task estimates and commitments during iteration planning, even after so many years of working with agile and scrum, I have seen many organizations involve only the senior members, leads and architects for sizing at release planning time or during backlog refinement sessions. Release level, and sometimes, sprint level commitments being made without full involvement of the team will lead to lack of ownership that you expect from a team to successfully deliver on those. There is no better way to educate inexperienced team members on the product features and in estimation than by involving them in the process. Even if some of them are relatively passive due to their lack of domain or product experience, they will learn by observing the discussions in the team before estimates are finalized.

4.Number of days as a substitute for story points

How often do you see teams estimating story points (size) for stories and epics after figuring out what it takes in terms of number of person days of effort? Don’t you typically estimate how big something is before estimating how long or how much effort it is going to take? For example, you decide on the complexity or difficulty of a feature or a defect and assign effort to them based on that estimate. That is the right sequence since size is independent of who is going to work on a feature and how much it is going to take or cost, which may vary based on the experience or expertise of the person doing it. Size estimates are important for planning at a higher level and for figuring out whether a team is doing better over time. For example, a team may deliver 30 story points in an iteration at the beginning of a release but as they get more experience and collaborate better, they may be able to deliver 40 or 50 story points in an iteration over time. If you used number of days as a surrogate to measure story points (size) in this case, that will not change over time, with the same team putting in the same number of days every iteration. And if you keep estimating size from effort, the size will keep changing based on effort estimated or spent, even if the scope has not changed. That doesn’t sound right, don’t you agree?

One way organizations have gotten around the need to do any sizing is by splitting epics into somewhat similar sized stories so the number of stories, in an approximate sense, represents the size of a feature to be delivered. This requires maturity and if this is possible, it is one way to get around this issue.

There are other anti-patterns in an agile estimation / planning context. What I have mentioned are the top issues in my view. What has been your own experience with agile estimation?

JV