This article was written with Jacek Wizmur-Szymczak of Spartez.
Every planning or grooming session, where team members meet to estimate stories and work items, has its own rules. Sometimes we haven’t estimated for a long time, the backlog is huge, and time is limited. Sometimes we have a team that can meet in the same office, sometimes it’s distributed and work is in different time zones. Other times the team is engaged and prepared, and sometimes they are bored and not motivated.
Sounds familiar, right? Here is a set of proposals for how to tackle the most common issues around planning and which methods of estimation to use.
Issue #1: Guesstimating rather than estimating
During planning, many teams use physical cards to play Planning Poker which is a consensus-based estimation technique. Each participant uses cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100 which present the number of story points. With that kind of planning, team members estimate based on a combination of their knowledge and gut feeling. They don’t use historical reference points or lessons learned from previous sprints. Their estimations are more or less at the same level of accuracy as the previous one. The main issue, however, is that there is no motivation for teams to improve their estimation accuracy from sprint to sprint. So, how can we encourage teams to refine their estimation techniques?
Solution: Prepare yourself better and use tools that store history
As a Scrum Master, choose issues from previous sprints as reference points. These historical issues will be benchmarks for the whole team to secure a better understanding of future estimates.
Another good practice is to show issues that were estimated previously as given story point values – e.g. three issues previously estimated as 1, 3, or 5 story points. Thanks to that, your team will have much better context.
Why is it so important? In many scenarios, team members have a different understanding of how big the points are. Giving them examples and a bit of history helps them come up with more accurate estimations.
Issue #2: When estimating, some team members try to convert story points into units of time
All of us have heard jokes about developers talking with their managers about estimations and expectations. It seems that the biggest thing to overcome is converting and calculating story points into days and hours anyway, rather than comparing issues with each other. This happens a lot when development teams are estimating with management. Consequently, that misunderstanding leads to frustration on both sides. How can we better align the expectations between teams?
Solution: On a project or epic level, try t-shirt sizing rather than story points
In this method, instead of using numbers from the Fibonacci sequence, your team will use sizes of t-shirts – S, M, L, XL.
As “State of Agile report” states – 51 percent of teams use points, 23 percent of them use t-shirt sizing. Both methods of estimation have their own benefits. If you struggle with people that are converting and calculating story points into days and hours, try T-shirt sizing first. This method is more abstract than story points so it’s harder to convert them into units of time (since t-shirts sizes are not numbers). When your team learns how comparing issues with each other works in practice and why it’s better than estimating in work-hours or days, you can then proceed with story points.
Issue #3: Too many issues to estimate
In a short amount of time, a backlog can grow exponentially. Suddenly there are 50, 100, or more issues in Jira to be estimated. Everybody knows the feeling when it’s clear it will not be done in the time you have allocated for the estimation session.
Solution: If you have many issues to estimate, try Relative Sessions
Relative estimation is one of the fastest techniques used for estimating projects. It’s based on the well-known Planning Poker alternative – Team Estimation Game – which helps teams sort features and user stories based on relative complexity. Team members compare issues and decide whether one requires more or less effort to be completed than the other. Individually, one at a time, a team member takes a new card from the backlog and puts it on the board or changes the position of a previously placed card.
Issue #4: Teams operation in different time zones
Your team is distributed and you want to run planning session to estimate your backlog with all team members. You work in NYC and your team operates from New Delhi. This often requires staying late or asking people to wake up early. This leads to blurry-eyed, half-awake conversations over spotty internet connections (often with kids in the background demanding breakfast).
Solution: Try using online tools that have asynchronous modes of estimation
When it’s hard to estimate at the same time, try estimating when it suits the team best. There are tools that let you estimate whenever you like. They can allow the team to review it after the session ends and set a final estimation. Another benefit of this mode is that everyone has a voice and you’re avoiding situations where louder people have more to say.
Final thoughts on different methods of estimation
It doesn’t really matter what method you use, as long as they work and provide good outcomes for your team. There are a lot of different tools like Agile Poker for Jira that can help you find the way that will fulfill your team’s needs. Don’t be afraid to test and to try new things that may lead to the teams’ growth.
Learn more about Agile Poker on Atlassian Marketplace