Six learnings from working with estimating in Agile

One of the most discussed and explored topics in the software industry, arguably the most, has to be estimation. I have enjoyed coaching teams on how to use different approaches / techniques in their Agile context. Needless to say, I have learned a lot doing that. Here are the top six from my perspective:

1. The evolution of estimation and viewpoints around estimating

While effort estimation approaches have largely been based on work or task break down, size estimation has evolved from absolute estimation techniques (such as Function Point Analysis and Lines of Code based estimating) to those using relative sizing. Approaches such as Planning Poker, T-shirt sizing, three-point estimating (optimistic, pessimistic and realistic estimates) and high-level estimation for epics and features have evolved subsequently.

One of the more recent trends has been to split the epics to almost similar (or approximately equal) sized stories and use only the number of stories to be delivered as a size measure, rather than do individual story size estimation. While this depends on the clarity of requirements/features, it usually works with teams that have a certain level of maturity in breaking down of the backlog/epics. It almost eliminates the effort spent on estimation, while not compromising on its main goal, which is achieving predictability.

For starters, an experienced coach may help in choosing the right approach for different situations / contexts while also helping with what to do for estimation at different levels (roadmap, release, sprint level etc.).

2. Relative estimation is simpler and more effective than absolute estimation approaches

Agile approaches mostly recommend relative estimation techniques when it comes to story or epic sizing. Their ease of use for planning at all levels has been the driving force behind their large-scale adoption. There was a time when questions were raised on how relative estimates (with no estimate of effort in person-days etc.) will help in projecting a schedule or making meetable commitments. Today, relative estimates together with velocity driven planning have clearly proven that you can make realistic commitments and be predictable, without getting into effort estimates.

As an aside, it is interesting to note that even absolute estimation approaches such as function point analysis have built-in relative sizing aspects – for example for different function types with grading of levels of complexity for each of them before assigning specific number of function points. They are complex to use, rely on a lot of industry-wide past data and require comprehensive guidelines for ensuring a uniform or repeatable approach across teams, and organizations. Even then we often find two different FPA estimators coming up with two completely different numbers for the same application. Having had extensive experience with both, I have personally seen relative sizing score better in terms of its simplicity and effectiveness of use.

3. Estimating in the “large” versus estimating in the “small”

When one looks at estimation approaches there is always a question of what approach to use at different levels – for example, should one use different approaches for estimation of large features (as may be required for budgeting or roadmap planning) versus estimating for tasks (as required during sprints)? Are relative estimation approaches useful at all levels of planning? I have personally found relative estimation approaches work for sizing large features / epics as well as small stories. You can use the same story point approach/numbers for sizing stories as well as epics.

However, I have personally found using a separate relative scale for epics – such as “epic points” – with a similar Fibonacci or other sequence – is a good idea. This helps you operate on the lower end of the Fibonacci scale, making it simpler and perhaps slightly more accurate.

At the other extreme, I have even encouraged teams to use a concept of “task points” for relative estimation for tasks (though most teams feel comfortable estimating in person-hours for tasks).

4. The case for “no” task estimates

Most teams feel comfortable about estimating tasks in person hours – especially when they use capacity driven planning. However, there are teams that use commitment or velocity driven planning that may decide estimating at a task level is not needed. Even so these teams should break down stories into tasks and sub-tasks and use daily stand-ups as a collaboration means to track and manage dependencies as well as task and sub-task completion so they are able to fulfil their committed sprint goals / planned velocity. As teams mature, this approach works very well, however, for teams that are relatively new, I recommend capacity driven planning with task/sub-task estimates.

5. You get better by actually doing it

I have seen many organizations use only senior developers / designers / analysts for story estimation since they believe “junior” developers can’t estimate. While estimation is a specific skill that needs to be developed, one needs to understand that you learn faster by doing it with others in the team and get better at it by practicing it on an on-going basis. Agile estimating approaches such as Planning poker involve all developers so they learn by observing and by doing it with their seniors. You need to ensure that even the relatively inexperienced get an opportunity to estimate and provide their perspectives right from the beginning while they absorb and learn from others’ perspectives.

6. Power of many minds / perspectives

Estimation in Agile typically involves all concerned team members / stakeholders – when you bring in a cross functional team comprising developers, testers, business analysts, Ux specialists etc. together for estimating any function or story, multiple perspectives come out and there is significant mutual learning. Team members getting together and looking at relative story sizes, debating and moving story cards around while doing and re-doing estimates using an estimation board, is a sight to behold and demonstrates the power of collaboration.

The other major benefit with this approach is the ownership it creates in the team for the estimates arrived at and as a result the commitment to live up to the estimates as much as possible. With the user stakeholders (through the POs or otherwise) also involved in the process, there is mutual understanding and appreciation of the complexities involved in the functionality to be delivered, all of which contribute to a healthy and productive environment.

There are a couple of things I would like to conclude with:

• Effort spent in estimation should be commensurate with the required outcome, which is a forecast to predict a commitment, based on information available at any time. So, accuracy of estimates does not improve with effort spent beyond a point. Relative estimation approaches at different levels fulfil this objective.
• Have not gone into discussing schedule / timeline estimation here since that’s a complex subject, heavily dependent on quality of software required at release. Real velocity achieved is often different from planned velocity, often because of technical debt caused by deferred fixing of defects, requiring additional hardening cycles. Possibly a topic for a future blog!!