Software teams can interpret being agile in different ways. And with plenty of agile techniques teams can lean on—sprints, retrospectives, and standups—estimates (interchangeably referred to as “estimating” and “estimations”) remain a point of contention.
One person might say estimates have no place in software development, while another would say using estimates is what defines agility with respect to development.
But let’s say you’ve decided to bring estimations into your sprints. Now come even more questions: Should we be estimating on projects, should we use the T-shirt sizing or story points method?
Despite estimates not being a one-size-fits-all approach, we wanted to add some clarity to the discussion and share how bringing estimates into sprint planning can help bring open up greater communication across software teams.
Why bring estimates into sprint planning?
Generally speaking, people are inherently bad at guessing how long it would take to complete a project without having a point of reference. However, it becomes much easier to provide an estimate if we compare it with a project we’ve previously done.
At its core, estimating allows teams to objectively look at a project during the planning phase to determine the level of difficulty associated with each Issue. This, coupled with historical data from burndown charts and velocity reports from previously completed projects, paints a better picture for software teams to gauge the output required to close out Issues during a sprint.
Valuing Issues and projects during sprint planning
Issues tied to a project are valued with a predetermined scoring method based on difficulty.
Most common scoring methods are T-shirt sizing (using values S, M, L, XL) and story point estimating, a method which uses numbers to score, for example, the fibonacci scale (1,2,3,5,8,13,21,40).
T-shirt sizing provides an easy way for teams to associate values to Issues without having to over-analyze them. Teams need to decide on the the range of points associated to each T-shirt size in order for this method to be effective. Once the range of points are set, t-shirt sizing is the quickest way to decide how difficult Issues are and which one’s can be prioritized into an upcoming sprint.
With story point estimating, teams can use different ways to determine how to rank an Issue. Team members use points to rank how complex they believe an Issue to be.
For example, Issues ranked 1,2,3,5 are considered easy to moderately complex, whereas Issues ranked 8 and up are often seen as more complex, and should prompt further conversation from the team to figure out how they can break down these Issues into smaller, more manageable tasks.
When you should start estimating
Estimating is most impactful when teams start to unpack and prioritize their product backlog. Once values are allocated to Issues from the product backlog, they can start to package these Issues together to work through during the next sprint.
With use of velocity reports and burndown charts software teams are able to match their original projection of speed to close out Issues with data previously collected from past projects. The estimations themselves aren’t meant to be perfect. In fact, they likely won’t be. Though with time and practice estimating gets easier and more accurate.
We encourage teams to start at least thinking about bringing in estimations into sprints. For teams interested in getting started with story point estimating we’ve created a helpful guide on how to estimate work using story points. Feel free to use this guide as your playbook to estimating. If you have any questions, you can reach out to our Customer Success team who are happy to walk you through how to start using estimates.