Facebook
Twitter
LinkedIn

Models Playing Planning Poker

Software estimation is difficult. Programmers tend to be short-term pessimists and long-term optimists; this skews estimates in many directions. Product owners often struggle to describe what they want in a way that a developer can accurately estimate. And, at the end of the day, we as humans tend to forget the bad and remember the past with a certain nostalgia, hurting our ability to estimate accurately. Here are some patterns we’ve noticed in our work that cause estimates to be inaccurate.

Not using relative sizing/story points

Asking your developers to estimate how many hours a task is going to take is a slippery slope. First, we, as developers, often struggle with giving correct time. Second, think about the spicy food-truck conundrum, the problem that happens when “developer 1” ate too much spicy food-truck food and couldn’t come to work due to “intestinal discomfort.” All the sudden, you are left with “developer 2” and “developer 2” might take twice or half as long as “developer 1” for any number of reasons. While being off on a task or two won’t kill a project, when 10 of those tasks pileup, your project will slip.

Instead, agile practitioners favor the use of story point estimation. This technique groups product backlog items (PBI) together that should take a similar amount of time. If you rank two PBIs a 5 they should be relatively equal in effort. Once you have your relative size assigned, you use “yesterday’s weather” to decide how many story points your team can do in an iteration.

Getting estimates too detailed too early

If you’ve been in the project management business or software development business more than a minute or two, you’ve come across the Gantt Chart from Hell (GCFH). It usually requires 4 monitors to display, has hundreds of rows on it with arrows pointing all over the place, and is truly your project manager’s baby. You know, the ugly one that on one wants to admit is ugly.

Issues with the GCFH is a topic in itself. For now, I’ll highlight a key problem with the GCFH: if you feel you can plan your project at a high level of detail for any time beyond the next 24 hours, you are a better fortune-teller than most. Software development is far too complex and unpredictable to be accurately planned to the hour or even day or even week.

Instead, use concepts such as “yesterday’s weather” and relative estimation to estimate your projects on a sliding scale. You can create product roadmaps that have a year or two on the forecast, but adjust the detail appropriately. You need to be agile and adapt to change; so make sure your long-term planning is flexible and reflects uncertainty.

Not involving enough people in your estimates

A common failing of new project managers is to rely on a few key people to generate estimates. Effective estimation is a whole-team effort. Your testers and analysts have just as much to say about the complexity of something as your developers do. Good agile estimation requires good team communication and discussion.

Failing to inspect and adapt

As an agile team you should constantly be inspecting your results and adapting your estimation based on validated learning. Every few iterations you should take time to check your estimation process. Determine if something that you once assigned 5 story points to is still a 5. Don’t change what you did in the past, instead, apply that learning into what you are doing today and make sure it’s reflected in your next estimation session.

Not taking the time to get your team on the same page

Taking the average of everyone’s estimate is a pattern I’ve often seen and done in estimation meetings. While this could be a way of coming to consensus, it should never be a tool to avoid conflict. The absolute most important tool in exact estimation is team conversation. Instead of jumping to an average, have your team discuss the reasons for different estimates. Encourage healthy conflict and strive for true consensus. If you can’t reach it, then be introspective and find out why. If you avoid conflict you might never find out what is hurting your estimates and you won’t have the opportunity to improve.

 

 

Comments

Leave a Comment

Related Posts

5 Ways to Encourage Your Team

Unlock team potential with practical Agile methods for Scrum Masters to motivate and support their teams towards success. #AgileGrowth”
March 13, 2024
Chris Sims

Daily Scrum Survival Kit

Unlock efficient Daily Scrums with our Survival Kit, featuring a must-use Sprint Burndown Excel Template. #Agile #ScrumMaster
March 11, 2024
Chris Sims

How to Conduct Your First Happiness Survey: A Step-by-Step Guide

Discover how to boost team morale and productivity with our step-by-step guide on conducting your first happiness survey. Learn essential
March 6, 2024
McCaul Baggett

Prompt Engineering for Scrum Masters and Agile Coaches

GenAI enhances Agile practices, offering Scrum Masters and Agile Coaches tools for innovation and efficiency in product development.
February 29, 2024
McCaul Baggett

The Top 5 Tools Every Agilist Should Know

Explore essential Agile tools across 5 categories to enhance collaboration, project management, feedback, and more for Agile success.
February 27, 2024
Chris Sims

Organizational AI – 5 Reasons Your Organization is Failing at AI

Maybe you’ve imagined automating the mundane tasks, uncovering insights from data that were previously hidden, or simply revolutionizing the way

February 22, 2024
McCaul Baggett

Elevate Your Agility

Subscribe to our Blogs
Select the coaching guidance you would like in your inbox.
Scroll to Top