Navigating the world of fashion sizes recently got me reflecting on three principles from agile estimates and sizing practices.
I was trying on clothes with the help of a stylist.
“Oh my gosh, these pants FIT! No alterations needed! Did you say they’re a petite size 6? Unbelievable.”
I was shocked at how well the slim pants skimmed my bottom half. My closet contains two pairs of trousers that are too tight around my hips to wear. They’re sizes 8-10 from another brand. Other pants that fit me well are a size 12. Finding suitable tops can be just as frustrating.
If you’ve tried to buy women’s clothing as a gift for someone, you may have struggled to make sense of the sizes too. The average size of an American woman has been reported as a size 14; many fashion brands do not carry sizes above 12. The system almost seems difficult to understand by design. And while men’s clothing seems more straightforward, picking a pair of pants from a store like Banana Republic is not the same as looking for pants at Bass Pro.
Estimates from agile teams can seem random or inconsistent without understanding the principles behind them.
Thinking in Relative Estimation
Relative estimation helps us understand the size of items compared to one another.
Putting aside numerical sizes for a moment, let’s consider how t-shirts are often sized: small, medium, large, and extra large. When I worked at a clothing store in college, I made sure that items were in the right place and sorted by size. Customers could find what they were looking for, and it became easier for us to know what inventory we had.
T-shirt sizing is often used by agile teams as a first step in estimating work items. Using physical cards or in an electronic tool, a team will sort product backlog items into groups. Items that will take a small amount of effort go into one group. Another group has items that will take a medium amount of effort, and so on. This is usually a quick sorting activity to get a sense of the work and see where further refinement is needed.
Many organizations want predictable delivery from their agile teams. Coordinating cross-team dependencies leads them to take their agile estimation efforts a step further and use numerical estimates of some kind.
The Value of Numbers for Estimates
Regardless of clothing brand, there is consistency that a size 6 is smaller than a size 10 and larger than a size 2. Here the numerical sizes act as buckets where we group items of a similar size together like t-shirt sizes allow us to do. The difference is that we have more size options available when using numbers.
While the clothing sizes labels use numbers, there is not an easy-to-apply formula to tell us how size 10 pants compare to size 2 pants. Size 10 pants are not five times as large as the size 2 pants!
Agile teams do not use numerical estimates to have more size “buckets” to choose from. The primary reason is that they want to do math with their estimates.
Some teams use estimates to determine how many product backlog items they can deliver in the sprint they are planning. Most agile teams use estimates to forecast delivery of future backlog items. While there are ways of accomplishing both of these goals without using estimates, a popular method is to use numbers for story point sizing.
In story point sizing, the agile team selects a set of numbers to use in estimates. Often they use a modified Fibonacci sequence for their story points. A story point has no fixed value.
Teams add story point estimates to product backlog items during refinement sessions or update them during sprint planning. At the end of the sprint, the team adds up the story point estimates of the items that met their Definition of Done. Tracking the average sum over many sprints can act as a “confidence check” in sprint planning. It also provides greater predictability in forecasts of when future backlog items will be delivered.
Because the team uses the sum of their estimates to make decisions, it is helpful to check with the team that the math between sizes holds up. For example, if 2 and 8 are possible story point estimates, are 8-point items roughly four times the size of 2-point items? It is easy for teams to inflate estimates without realizing it when they don’t cross-check the relative size of items periodically.
Biasing the Numbers
Without context, we often interpret wearing size 4 pants or hearing a team estimate a backlog item as 5 story points as small and “good.” The truth is, “size 4” does not have a universal meaning in terms of inches or centimeters. And 5 story points does not have a universal meaning in terms of time or complexity.
Many of us agilists learned from training or from experience that 13 story points is too big for a team to get done in a sprint. Independent of what team is doing the work, their velocity, sprint length, etc. We cast judgment in the blink of an eye and suggest slicing the story into smaller chunks.
Have we translated fatphobia into our agile estimation and planning practices?
We’ve been calibrating teams to normalize their story point estimates, often telling them 8 points is the largest to consider “ready” for a sprint. The intent is to encourage teams to slice backlog items into smaller chunks. Unfortunately, it can lead to teams lowering their estimates to appease strong-willed stakeholders in less psychologically safe environments.
Some organizations try to compare teams based on the number of story points they deliver in a sprint. They believe the more story points delivered, the better or more productive the team is. This is a silly way to judge teams’ performance. Teams may use the same modified Fibonacci sequence to size their work, but estimates do not translate across teams. Much like how my pant sizes vary from brand to brand.
I often joke that teams should go for pinball-like velocities. Let’s estimate in millions if they will be evaluated by how many points they deliver! Silly, I know.
We lose sight that estimate and velocity numbers only mean something for that team of humans with their diverse skills and experience in the product or area they’re working on.
Years ago, I coached a team that was enhancing the login capabilities on a website. They came to understand the work extremely well. Their delivery was the most predictable I’d ever seen. My first reaction was to be skeptical of their estimates. I had never seen a team be so spot-on with their delivery.
Then they volunteered to upgrade the website’s content management system, which most of them had no experience with. Estimating and planning felt like a guessing game until they learned more about the system. The effort was different from their previous work, and they were not as predictable in their delivery at the start. Same humans + different products = different velocities.
We do ourselves and our agile teams a disservice when we read too much into the numbers.
Focusing on Fit
Story point estimates can be useful for agile teams when practitioners keep in mind a few principles:
- Agile teams need to determine if backlog items are small enough to fit within a sprint, too big, or un-estimable due to unknowns. They may use numbers to do this or not
- Unlike women’s clothing where size 12 is just a couple of sizes larger than a 6, we understand 8 story points to be more than double the effort of a 3-point story (math FTW!). It is important to check that this relationship between the numbers is true when the sum of estimates is being used to make decisions
- Numbers coming from agile teams are contextual. Estimates and velocity only mean something for that team of humans with their diverse skills and experience in the product or area they’re working on. Recognize when you’re judging teams based on their numbers and check your bias
Understanding women’s clothing sizes is still a guessing game to me. But I’m learning not to take the numbers too seriously.
Thankfully, estimation doesn’t have to feel like a guessing game or source of stress for agile teams. If it is currently, then revisit what estimates need to do in your organization.
Estimation and Planning is one of our most popular Agile Accelerator Workshop topics. We love to help teams avoid common agile estimation mistakes and learn how to use estimates for release plans. Most importantly, we unravel teams’ issues with long-term forecasting based on vague estimates!
