02May
INVEST Guidelines – Estimable Criteria

  

In this fourth article, it is analyzed the meaning of E from INVEST mnemonic: Estimable. A high-quality user story must be estimable. Usually in Agile, estimation is a relative one; relative to the rest of the user stories in the backlog. Various methods are popular: Fibonacci series of numbers, T-shirt sizes (small, medium, large), etc. The effort consumed by the team to put a relative estimate on a user story should be minimal, but all team members must agree on the estimate before it is recorded. 

But in order to provider a good estimate, the team must understand the user story. The user story must be small and focused; the acceptance criteria needs also to be known and clear because the estimation must cover the design, development, testing and documentation of the feature implemented.

Getting a user story to this point requires negotiation between the team, product owner, and customer. If the user story is not clearly defined or scoped, the team will not be able to estimate the level of effort. And the estimate is important because it's used to determine if the user story can be completed in the single sprint. Once the team has a stable velocity, the user story estimates help them determine which user stories will be pulled in the next sprint. Let's say that the team has a velocity of 7, and the two-top-level user-stories in the Product Backlog have 4 and 6 story points. The second user story cannot be pulled in the same sprint with the first one because then the Spring Backlog will have 11 story points while the velocity of the team is only 7. In this case, either the second user story is planned for another sprint, or the team can look into it to see if it cannot be split is smaller user stories which can be handled in the current sprint. 

Also, the rule that every team member needs to agree on the estimate almost guarantees discussions that'll bring out uncovered assumptions and missing requirements. If the QA team member thinks the story is large, while the GUI team member thinks it's small, there's obviously something one knows or assumes the others is not aware of. More discussion is needed to fully understand the user story. This discussion around estimates brings the entire team to a shared understanding of what is required to complete the user story. Now when a user story cannot be estimated, it is because the team cannot get their collective head around the entire story. This is normally because the story is too big or has several different features in the same story. In this case, the story should be split into multiple stories. In other cases, the story has too many unknowns requiring research. 

A user story that is unclear will normally be estimated quite large by the team. Even if a user story is high priority, if it can't be pulled into a sprint, it can't be worked. Now these large user stories probably contain multiple features which are each at different priorities. Splitting a user story into its component features allows each feature to be prioritized individually in the product backlog. Lastly, the team is solely responsible for estimating the level of effort. The product owner says what will be delivered by maintaining and prioritizing the product backlog, but the team says how much effort each product backlog Item will take to implement. 

The "E" in the INVEST guidelines stands for Estimable. The feature or requirement described in the user story and its acceptance criteria must be clearly understood by the team in order for them to give an accurate estimate of effort.