.png)
.png)
.png)
.png)
.png)
.png)
Estimation has sparked many debates within software development teams. There are various ways of estimating, all with one thing in common: they are all just a best guess.
Reading about the pros and cons of estimation, most of the cons focus on the estimate itself and its liability to be inaccurate, interpreted as a guarantee or used to judge team performance. The main complaint about the estimation process is the time wasted when teams could be working instead.
Estimating has come a long way since the days when time estimates were standard (not to mention, they were particularly ill-suited for complex work in unpredictable environments). Relative estimation was introduced as a simpler, quicker and more accurate method of estimating. Rather than evaluating work in isolation, work is compared and grouped by effort. Effort factors complexity, risk and uncertainty into estimates rather than just the expected time required. Teams can draw on empirical evidence and benefit from experience by comparing upcoming work with that already done.
The units commonly used in relative estimation – Story Points and T-shirt sizes – are much less granular than traditional time-based estimates. They also become increasingly less granular towards the higher end of the scale, recognising the need to be less precise in estimating larger, more complex items of work. Eliminating the need to be precise speeds up estimation considerably and makes the estimate more likely to be accurate.
Planning Poker is an estimating technique adopted by many teams using relative estimation with story points. It facilitates a consensus on estimates by engaging every team member; each must consider their estimates separately before simultaneously revealing them. They need to think for themselves and explain their choice rather than simply agree with someone else.
Unfortunately, relative estimation doesn’t improve the usage of the estimate itself, which can still be mistaken for a guarantee and relied on too heavily, sometimes resulting in deadlines and unhealthy pressure being exerted on the team. The use of story points introduced a new issue as points estimates count towards velocity (the total story points a team completes in a Sprint) which often gets misused as a performance metric. This can lead to teams artificially inflating their estimates to give the illusion of higher performance, making their estimates unreliable.
Some teams find relative estimation difficult to get to grips with too. Story points are unique to each team, so when members switch teams, the transition is not seamless. The differences in point values between teams can also confuse stakeholders working with multiple teams. It can take time to explain the concept to new team members and there may be resistance from those who haven’t taken to it.
Given the drawbacks, it's perhaps not surprising that teams are tempted to pack up the planning poker once and for all and give up on estimating as a lost cause. However, I wonder what they would be missing if abandoning estimates was a viable option for them.
While many teams might not have the power to decide whether or not they estimate or how, and may be unable to influence how others use estimates, it is in their power to reduce waste in their estimating process. In doing so they may make estimating work to their advantage and begin to see the time spent as a worthwhile investment.
Sources of waste in relative estimation
Thinking in time rather than effort
When teams have the option of using less precise methods of estimation, why would they continue to estimate in hours? There is a popular saying that “old habits die hard” – perhaps people are just used to considering how much time something will take.
I worked with a team that found it hard to break away from time estimates despite embracing Story Points. They didn't like to admit it to me, aware that it wasn’t the correct way to use Story Points, but they had a formula for converting hours to points. The time estimation didn’t stop there; after a consensus was reached on Points, each Story was broken down into tasks and estimated in hours. The total hours given to tasks would often lead to the Points estimate being revised.
As you can imagine, this took up quite some time and you might wonder why they didn’t just switch back to estimating in time. Although often missing the point of relative estimation, they appreciated that Story Points allowed them to provide less precise estimates that stood more chance of being accurate. Story Points also fed into velocity, which was beneficial as a guide during planning. The team were aware that their time estimates often reflected a happy path through the work, and increased points estimates to account for complexity, risk and uncertainty when needed.
Lack of commitment to the process
Relative estimation requires teams to spend some time upfront getting to grips with the concept and identifying appropriate examples of work to use as benchmarks. Benchmarks will have to be revisited periodically, especially when new team members join or the type of work changes. A failure to do so might mean newcomers abstain from estimating and struggle to engage in estimation sessions, taking longer to get up to speed as a result. Over time, team members may become misaligned on their interpretation of estimates, making it difficult for them to agree. This should signal the need to identify more familiar benchmarks and recalibrate Story Points to realign and speed up the estimation process.
Estimating based on who will pick up the work
Relative estimation considers the size of the work in terms of effort (complexity, risk and uncertainty) rather than the time individuals would take to complete it. This eliminates the need to account for different levels of knowledge and experience within the team when estimating. With this in mind, teams shouldn’t be spending time discussing who might pick up the work and whether to increase the estimate to enable less experienced team members to work on it. Aside from wasting time, in making these early decisions about who works on what, the team reduces their flexibility.
Story pointing anything and everything
When using Story Points and velocity, teams only need to estimate Product Backlog items, as it’s only the total points attributed to these that count towards velocity. Velocity exists to guide teams as to how many Product Backlog items they can expect to complete in future Sprints based on previous performance. Assigning Story Points to anything else (bugs, meetings, refinement activities, etc.) is a waste of time.
Gaming Story Points
Unfortunately, management often misuses velocity as a performance metric. This can encourage teams to artificially inflate estimates and waste time assigning points to tasks or activities which don’t warrant them (as described above). Some teams might constantly revise estimates throughout the Sprint to claim any extra points of effort should the work be more complex than anticipated. Teams who are conscious of this negative practice might feel exhausted by this need to “game the system.”
Wasteful practices regardless of the method chosen for estimation
Estimating too far ahead
If estimates are assigned to work too far down the backlog, work will likely not begin on them anytime soon. In the meantime, more could be learnt about the work which might make the estimate less accurate. It may even transpire that the work isn’t needed at all, rendering the time spent estimating wasted. There’s value in being aware of upcoming work and even discussing it, but spending too much time getting into the details and attempting to estimate it isn’t time well spent.
Failing to learn from estimates
Without inspecting estimates and discussing learnings from the work, teams can miss the opportunity to process this knowledge and use it to benefit future estimates. In my experience, learning from estimates often gets overlooked during retrospective discussions. While it may be mentioned that work was more complex than expected, it might take some coaching to get the team to identify the root causes of the added complexity and agree on any actions needed to better prepare them in future.
Failing to explore differences in opinion
Speed isn’t everything. Taking some time to ensure requirements are well understood at the estimating stage can prevent wasted time during development. When team members propose different estimates, lengthy discussions might ensue before the team can reach a consensus. I’ve noticed more impatient team members attempt to accelerate decision making by suggesting the team accept the majority vote, take the average estimate or plump for the highest. These shortcuts bypass valuable conversations which might reveal a simpler approach that convinces those with the higher estimates to agree on a lower one, or an added complexity that convinces those with lower estimates to accept a higher one.
Sweating the small stuff
While there is value in properly discussing estimates, a disproportionate amount of time might be spent discussing the smallest backlog items. There’s probably little value to be gained from debating at length whether to assign 0.5 or 1 point or 1 or 2 points. While it’s worth hearing the rationale for the higher estimate, briefly, to make sure everything is considered, teams shouldn’t be spending more time discussing the work than they would spend doing it. If it’s small fry, just pick an estimate and move on.
While there’s value in agreeing on estimates for backlog items as a team, if developers want to break these down further into more granular tasks, it doesn’t need to be a whole team activity. There is little value in estimating them either.
Conclusion
Teams can make estimating work to their advantage by eliminating wasteful practices and focussing on the outcomes which enable learning, effective collaboration, inspection and adaption. These outcomes include:
Clarification of requirements
Estimating encourages teams to clarify requirements and share knowledge before starting development. Of course, thorough discussions could still take place without estimating, but the need to reach a consensus and agree on a size increases participation and adds weight to the conversation.
Increased predictability
Teams can use estimates to predict how much functionality they expect to deliver in a Sprint. By improving estimating practices they can increase the accuracy of these predictions and make
planning easier.
Indicator of progress
Estimates can be a valuable point of inspection for teams while the work is in progress, serving as a reminder of what was expected at the outset. If the effort required exceeds expectations, this may highlight the need to revise the Sprint plan.
A point of reference to inform future work
Teams can learn a lot from comparing estimated effort vs. actual and exploring the reasons behind any variance. Where did any extra effort originate from? Can they tackle the root cause to make future work more predictable? Answers to these questions can reveal dependencies, knowledge gaps, unstable areas in the codebase, etc. By making these visible, they can be prioritised and dealt with, or at least accounted for in future estimates.
In agreeing on the actual effort required by completed stories, teams can use these as benchmarks, making relative estimating simpler and more accurate.
With some fine-tuning of the estimation process, the time invested could be much better spent.
