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.

 

 

You have the training.
Now you need the job.

Unlock your potential with our new course: ‘How to Build an Agile Resume’. Dive into impactful lessons, gain exclusive insights, and join our Launch Party!

Comments

Leave a Comment

Related Posts

Welcome Changing Requirements even late in the game.

We Welcome Changing Requirements

Explore how welcoming changing requirements in Agile development provides a competitive advantage by adapting quickly to customer needs and market
May 9, 2024
Chris Sims

Individuals and Interactions

The Agile mindset has transcended its roots in software development to become a vital component in many ways of working

May 8, 2024
McCaul Baggett
Emotional Intelligence

Emotional Intelligence in Agile Leadership

Emotional Intelligence (EI) has become a crucial skill in Agile leadership, enhancing team dynamics and adaptability in our rapidly changing
May 7, 2024
Matthew Rodriguez
A young Jedi looking at himself in the mirror, seeing an older wiser version of himself with experience

Experience vs Certifications: The Agile Dilemma

Oh, what joy! Another day, another credential. You’ve just added a shiny new set of letters behind your name, thinking

May 3, 2024
Corey Stewart

Navigating Agile Transformation with Generative AI 

As we continue to witness unprecedented growth and transformation in technology, the potential for Generative AI (GenAI) to revolutionize Agile

May 2, 2024
Denise Jarvie
Retrospective Toolkit

Retrospective Toolkit

Explore our Retrospective Toolkit to enhance Scrum sessions, address challenges, and improve team dynamics for continuous growth and efficiency.
April 29, 2024
McCaul Baggett

Elevate Your Agility

Join our free weekly coaching tips
Unlock your potential with free, bite-sized Agile training and coaching delivered straight to your inbox. Learn from leaders with practical experience in Agility.
Scroll to Top