ProductFTW #10: How to Get the Team to Estimate

In ProductFTW #9, we explored how accurate estimations can prevent burnout and frustration. It's important to clarify from the outset that, as product managers, we don't perform the estimations ourselves; rather, it's the engineers who estimate the time and effort required for tasks. Our role involves understanding, facilitating, and utilizing these estimations to communicate with stakeholders, plan roadmaps, manage dependencies, and set overall expectations. Without accurate estimations, executing our role effectively can be challenging.

So, why are we even writing this post? Your primary role is to deliver the product exceptionally and reliably. To achieve predictability, the engineering team needs to execute your plans with precision. I don’t know a single engineer who would volunteer to estimate their work. They often require encouragement, sometimes even pressure, to make estimations. In startups and smaller companies, this task of persuasion frequently falls to the product manager, who balances collaboration and enforcement with the engineering team.

Talking about estimations can spark a bit of a debate. Every place I've worked, it's the same story: engineers see it as a nuisance, a distraction, even calling it a SWAG (scientific wild-ass guess). But here's the thing: we're aiming to turn those wild guesses into something a bit more solid and backed by data. We've got to start somewhere, right?

Engineers aren't fans, and I get it. They're all about accuracy, and estimations just don't fit that bill. It feels like going against the grain. No team I've been part of was ever thrilled about it, and the smaller the team, the louder the groans. But despite the pushback, sketching out even a rough timeline is non-negotiable. It’s not just about us in tech; it’s about the entire company working together in sync.

I’d like to think that the mention of estimations makes engineers momentarily forget that there's an entire team outside of technology that relies on our guesses to plan and execute their own work. Without us providing some form of timeline, the marketing team is left in the dark about when to align PR efforts, set teasers, or even draft copy. Similarly, the sales team can't set realistic expectations with prospects, potentially leading them to make promises we can't fulfill. The list of people and teams that rely on estimations can go on and on because they really are that important. So, the question is, how do we build the data behind the SWAG? We need to get organized and select a framework for measurement. The biggest challenge is getting everyone on board with whatever framework they choose. It's about making sure everyone's on the same page and agrees on what each estimate means.

Some Popular Estimation Frameworks

Planning Poker

Planning Poker combines consensus, gamification, and the wisdom of the group to make estimation more accurate and engaging. It avoids the influence of the loudest voice in the room and encourages everyone to contribute, making it a democratic way to reach a shared understanding of task sizes.

How it Works:

• Each team member gets a set of cards, each representing a different level of effort (typically using the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, etc.).
• A user story or task is presented, and after a brief discussion, each member selects a card representing their estimate of effort.
• All cards are revealed simultaneously. If estimates vary significantly, a discussion follows to understand different perspectives.
• The process is repeated until the team reaches a consensus.

T-shirt Sizing

T-shirt Sizing simplifies the estimation process by categorizing tasks into sizes from XS to XXL, making it an accessible approach for all team members. It's particularly useful for high-level estimations or when detailed information might not be available, promoting relative comparison over exact time frames.

How it Works:

• Tasks are estimated based on relative size categories (e.g., XS, S, M, L, XL, XXL) instead of specific time units.
• The team discusses each task and agrees on a size that best fits.
• This method is often used for high-level estimation, especially in the early stages of planning.

Bucket System

The Bucket System is a fast and efficient method for estimating a large number of items by grouping them into predefined buckets of effort or size. It encourages relative thinking and is dynamic, as items can be moved between buckets as discussions progress and consensus is formed.

How it Works:

• A set of buckets is created, each representing a different level of effort or size (similar to the categories used in Planning Poker or T-shirt sizing).
• Each task or story is discussed briefly, and then team members place them into a bucket.
• Tasks can be moved between buckets as the team discusses and reaches a consensus on their relative effort or size.

Big Rock/Small Rock

The big rock/small rock system attempts to minimize sizing effort, with the ideal ensuring a sprint has a bit of extra room and nothing spills over. Picture a bucket and see one big rock inside, with a series of small rocks. This can work especially well in a sprint team with a variety of cross-functional engineers, but giving a primary story (big rock) to each engineer by specialty (e.g., data, mobile, API, etc.). 

How it Works:

• Engineers size tickets based on their expertise or planned assignment into big vs. small
• Depending on how your team sizes this, each engineer can only do one big story per sprint and then 3-5 smalls.

This process aims to ensure that committed tickets are completed but leaves more uncertainty. As a product manager, you must have a well-groomed backlog, as this often leads to some additional capacity to bring in extra tickets. The “spaces” left in the bucket are for urgent fixes or mis-estimations.

After choosing a framework, go through the last few months of tickets and size them up. This acts as your baseline. Yes, there will be debates and adjustments, but that’s part of the process. Getting everyone aligned on what the sizing actually represents is key. Next up, size the stories for your upcoming sprint. Post-sprint, take a hard look at how accurate those sizes were. It’ll be messy at first – expect that. What you’re digging for is the 'why' behind any misestimations. Were there unforeseen dependencies? Was there complexity or an external factor like techops alignment that could have been planned better? This is your chance to learn and adjust for future sprints. Recognizing these patterns helps refine your approach to estimations and planning, especially in accounting for those dependencies and complexities earlier in the process.

As the product manager, your role is to keep the team on track, encourage reflection on what didn’t go as planned, and document accurately estimated items for future reference. And yes, there’s a bit of a product manager’s insider tip: whatever the engineering team’s estimation, tack on an additional two weeks. This isn’t just for laughs; it’s practical advice. Even when you start to trust the team's estimations, those extra two weeks can be a lifesaver for handling the unexpected. Always aim to overdeliver, not underdeliver.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.