Estimating; the good, the bad and the ugly
Estimating isn't an exact science, here are some of the good, bad and ugly practices when thinking about sizing your work.
The good
The 3 C's of great team estimations :
Clarity
Teams that estimate well have a good grasp of what it is they are delivering for the item they are estimating. Doing estimations as a team, using a technique like Planning Poker, gives an opportunity to collectively agree on what is needed. For example, a developer tasked with delivering front-end code can make their expectations of what they need from the backend clear, meaning both parties know what is needed. Another alignment point is when the amount of work for one team might be much great than for another team. For example, a simple code change might deliver a raft of use cases that need testing. Or vice versa, a complex code change might only impact a small number of functionalities. If the deliverable is clear, the estimation of the work is more likely to be correct.Cadence
Teams that are mature in their estimation processes start to accurately predict what their cadence for delivery is. They can also judge the impact variables such as absences, team members changing or new technologies might make to their cadence. A measure of cadence might be story points delivered in a sprint.Capacity
The aim of estimation is to create a sustainable level of output that adds incremental value to the product, without creating burnout in the team. Teams that are well attuned through their estimation practices can understand what their maximum capacity is and how long that can be maintained without being detrimental.
The bad
Why do teams struggle with estimating their output and how to mitigate some of these:
Too many unknowns - the work has not been adequately described or broken down. If the issue is around what is being delivered, this can be resolved by using techniques such as Specification By Example. If the unknowns are around the implementation, then spikes to learn more about the work can increase understanding to better estimate the deliverable.
Lack of ownership - if constraints have already been imposed such as the end date or the cost of a deliverable, without input from the team delivering it, the estimation process can be undermined. Allowing the team to do their estimations and comparing them to any commitments will shake out discrepancies.
Estimation not valued - any experience of estimations being ignored or overwritten will inevitably lead to a devaluing of the process. Estimation takes time and learning to evolve and improve and teams should be supported through this.
The Ugly
Estimating can turn ugly when:
Estimations are treated as guaranteed deliverables. They are the team’s best view of the work given what they know. Steps to improve accuracy and how to best understand what is being asked should be reviewed through a retrospective.
Story points are extrapolated back to time. Story points are purposefully used instead of time to establish a cadence of delivery within the context of a full working life. It doesn't work well if these are reverse-engineered to try to establish some other view.
Assuming that adding X amount of people will improve output by the same factor, this is rarely a linear equation. Adding new people to teams can require existing members’ input to get them up to speed. This can really add pressure to teams, especially around delivery pinch points like product launches.
Can I help?
If your team is struggling with estimations, I can help. If that's understanding particular struggles and coming up with an action plan to address them or introducing estimating practices if they aren't already in place. Get in touch to discuss more.
