Article Series: Better Estimations in Scrum — Part 2: The Team View

When interacting in a scrum meeting with your team, there are several best practices to consider that will help team members provide better estimations. In our article here, we will explain in detail what some of these best practices are.

As we discussed in part 1 of our article series, having precise estimates allows for team growth and members feeling confident in their capabilities. This results in a team who works synchronously with each other while maintaining self-organization.

For part 2 of our article series here, we will assume that the team uses Story Points to estimate.

At White Prompt, we look at Project Management like taking a look under the hood. From ideation to production, our experienced project managers deliver peace of mind to our clients as the owners of the product roadmap. Our steadfast process involves communicating clearly and transparently, delegating, and managing the step-by-steps throughout the product’s lifecycle, for example. This allows for more accurate estimates of timelines and maintaining profitability.

If you are looking for the right team to build your next project, contact us today to schedule a free consultation and we will develop an out-of-the-box solution together.

Use all available points or sizes.

To begin, implement a planning session and use at least four values. For example, if you are using the Fibonacci series to point the Stories for a two-week sprint, use at least 1, 2, 3, and 5. A 2 should not be the same as a 1 or a 3. Be picky as it will help you create good reference tickets for future planning.

Don’t be afraid to use a “∞”or “?” if needed.

Sometimes the team can’t commit to a Story until they do not have more information or more analysis of the project.

Also, don’t hesitate to postpone the pointing to another session. Even with one day passing, there can be new information identified that can have an affect on the estimations.

Everyone participates, not just the experts.

This gives an opportunity to discuss gaps and make sure different points of view are fully covered.

For instance, a Story can be super easy to implement but very difficult to test. In such a case, if QA is not estimating, the team will probably fail in the delivery of the work by underestimating a test-intensive Story.

Avoid groupthink.

With planning sessions, collecting a wide range of estimates often happen. One person might have an 8 and another person may have a 13. Or, one person might have a 3 and the other person may have a 5. When this happens, the Scrum Master should ask the person with the highest number to explain to the person with the lowest number why this Story will need much more effort than they estimated, then compare.

The key point to remember with estimations is that they are a consensus-building exercise. In many ways the numbers are irrelevant. The important thing is that everyone reaches a consensus for how the whole team will deliver the Story at the end of the session and that it is productive for the project’s success.

Try to avoid having a discussion that concludes early for the sake of reaching a number, just to move on. They might say something like “since you have an 8 and you’re the expert I’m also going with an 8 just to keep the game moving”. It might take a few rounds of playing until everyone has reached a consensus that is acceptable. Note that it is better to have that discussion before the team starts delivering the Story, and the scrum Master should make sure that everyone has this conversation for a shared understanding of how the team will deliver the Story.

Break up items that exceed the maximum.

Let’s say that empirically the maximum for a Story to be delivered in one Sprint is 13. If a Story is larger than that, or if it has what seems to be an infinite number of estimations, the team can take several alternatives to make the Story more manageable.

One alternative is to create spikes in order to gain a better understanding. An output for the spike can be a roadmap to solve the Story of a POC that proves the work can be done.

Also, it is important to splice the Stories when possible. This excellent article provides great tips on how to do this to come to a solution.

No distractions during Story estimation

There is nothing worse than the lead developer playing on his cell phone during the discussion only to ask for a re-cap before he can show his card. Additionally, staying focused and not opening other browser tabs while estimating in a distributed team can be challenging with team members.

Try to remain focused throughout the duration of the meeting on the estimations. This will not only be more productive in the long run, but it is also a sign of respect for other members of the team.

Summary

Nobody has the secret to perfect estimations. An estimate is, by definition, “a rough or approximate calculation”, and it shouldn’t be taken as a fact.

With that being said, smart teams can mitigate the risks of bad estimations by honoring the process of estimating. Stay focused, be collaborative and maintain honesty with your team.

We think and we do!

Do you have a business that requires an efficient and powerful data architecture to succeed? Looking for a software development agency to make it happen? Get in touch with us at White Prompt today!