Sep 30th, 2021
Best Practices
Challenging Estimations
Written by: Scott Storlie, Senior Delivery Lead
At Clientek, we are fortunate to work with clients from all over the US across a variety of different verticals and with team members from several global regions. Headquartered in Minnesota, we are used to individuals being timid about asking for additional clarification on estimates because their questions may come off as doubting or insulting in some way. We see this same type of behavior from different regions of the US and in different areas around the globe, some more so than others.
In Agile, assigning story points to recognize the value of a story is fairly straight forward. All of our user stories are initially given an estimate by our execution team leadership for high-level release planning. As we progress through refinement, we perform additional story sizing with our execution team by applying a point value based on the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc). Utilizing this relative-size point structure, we gain a common understanding with our team and the client on whether a story is small, average, or large in effort and if the story needs to be broken down into smaller parts.
Story sizing is a critical component of refinement and proper release planning. During story sizing, it is imperative to give a voice to your team members, particularly when the team is not aligned on what the effort should be set to. Since stories are written from a user persona perspective, there is often misalignment on how much effort a story should be assigned. In many cases, it may seem simple to implement but turn out to be quite complex from a technical perspective, and vice versa. When this misalignment occurs, take a few minutes, and challenge each other on why there is a variance in estimated effort. In doing so, you will often find the following positive outcomes:
True Team Understanding and Ownership
The most common cause for story point misalignment is the execution team’s understanding of the story’s acceptance criteria. We often have our team members describe back to us their understanding of the story and from those descriptions we are usually able to diagnose one of two issues: 1) The story was unclear and needs to be refined. 2) They misunderstood the story the first time they read through it. Once we verbally walk through it, it becomes clear, and the story points can easily be reconciled.
By having this additional discussion and clarification when a story is brought into a sprint, the team’s task-out and overall execution becomes more precise. Moreover, now that the team has a concrete understanding of the story, they take more ownership of its completion due to their knowledge of the request and participation in its refinement.
Previously Unidentified Dependencies
A story’s impact to other system functionality is an easy thing to overlook when writing stories. Especially when the requested changes seem self-explanatory and straight forward to implement. Story sizing and misalignment of effort often bring new dependencies to the surface that need to be account for.
Without this additional discovery through story sizing, these unidentified dependencies can be found later in regression testing, or worse yet, in production, and have serious impacts to your release plan.
More Accurate Release Planning
With the team’s participation in ensuring a proper estimate, it is much less likely that additional stories get pulled into the sprint, only to have sprint planning show overcommitment according to the release plan. While the release plan often changes in minor ways from sprint to sprint, having the team get more accurate in their effort sizing directly reduces any major changes that put targets and timelines in jeopardy.
With so many benefits stemming from challenging each other’s estimates, it should not be a practice that we shy away from. The best teams are unified with a simple goal; to deliver the best product they can within the bounds of the project. Respectively challenging and remediating estimate discrepancies builds stronger team members, better team cohesiveness, and better products. If you don’t agree with someone’s estimates, tell them why you believe your estimate is more realistic and ask them to clarify their reasoning to ensure that everyone is heard. As a result, you’re giving your team(s) the opportunity to grow and become better.