Estimation

Businessman forecasting a crystal ball in the office

October 2 2020

Agile Estimation

AdamM Agile, Back to the Basics, Estimation, Planning, Tools 0

Estimation is hard. When we estimate tasks in the knowledge worker space we’re proven wrong more often than right. This is amplified when we try estimating projects, but still highly applicable when talking about estimating work on an existing project.

The best part is, this is no secret. From interns to the C-Suite we all know estimation is largely a false comfort. Most of us cope by assuming all estimates are off by some amount and we adjust our expectations accordingly. This is essentially the point of the cone of uncertainty.

Why do so many decisions in our industry hang on this precarious practice? Why, after all these years, have we not either improved estimation or moved on from it? What can we do to make this better for ourselves, our organizations, and our customers? At a guess, momentum, we actually have improved on it, and there are some ways to make it better and more useful.

To understand why we’re always trying to get estimates and basing our decisions on them we really need to step back and understand the role of estimates in the context of a project that is underway. Estimates help the team control work in progress. They also provide a data point for prioritizing work. On an organizational level, they help control risk. There are some people who use them as a measure of capability, but that is an anti-pattern and something that needs to be stopped when it’s found.

To move on from estimating we really need to replace the value estimation gives us. We need to provide a new way for a development team to control their work in progress. We need a new data point to help the product owner evaluate the cost, both time and money, of adding new features or functionality. Without a strong alternative to providing this data, we fall back on estimating. We have gotten better than a project manager trying to guess at person-hours for a feature though.

Through practices such as planning poker, fists of five, and affinity mapping we have gotten better at this game. As a team goes through these estimation practices they get better at understanding the work being asked of them, and over time how much work they can do. This results in the ability to more accurately determine how long new features will take and better control over the work a team has in progress. At its extreme teams may start to look into the concept of NoEstimates, but I’ll leave that for a future post.

If your team is struggling with estimation there are some things you can do today to help make it better. First, get rid of hours and days. Have the team come together and agree on an average task that they get. Once they have it, that task is now a horse, not a 3-day task. Every other task is evaluated not on its own – absolute estimation is the worst kind – but in reference to the one picked. If it’s bigger, is it a bear, an elephant, or a whale? If it’s smaller is it a llama, a dog, or a mouse? Relative estimation is far easier and more accurate and by taking people’s minds off the numbers they can concentrate on the work. When things are bigger than that horse, maybe send them back to the product owner to be broken down. When they’re smaller than the mouse, don’t waste time estimating, just add a couple to the work in progress and call it good.

The other big tip I’ll include today was foreshadowed above. The team. The entire team, not just the senior developer, needs to be part of the estimation process. This is also a great time to include not only the product owner, who is part of the team after all but also a key stakeholder or two so clarity questions brought up by the team can be answered more quickly.

I would be happy to help your team move a step or two forward on their journey of improved estimations. Just reach out to me and schedule a free call to get the ball rolling.

June 26 2020

Estimation, Planning, & You

AdamM Agile, Estimation 0

Estimation is an important part of planning but estimation is useful outside of planning, helping decision-makers and line workers both.

Estimation in an Agile setting should be done as a relative function: Option A is bigger, Option B is faster, etc. (If you disagree or don’t understand why let me know and we’ll have a chat, maybe even create a new blog post.)

Estimation outside of planning is a tool for decision-making. I know, isn’t that just planning? Not exactly.

Classic planning is all about a specific timeline and sticking to it as closely as possible through as much effort as possible. All risk possible has been assessed upfront and now is the time to act. Agile planning accepts changing conditions and addresses risk as it arises.

How does this relate to estimation?

In classic planning, a large amount of effort is spent getting the most accurate estimates possible at the outset, and those estimates are often used as gospel when controlling change later on. In agile planning, just enough estimation is done to make the next decision that needs to be made.

This doesn’t mean agile teams have no concept of how long the entire project may take. It does mean instead of promising they can finish in 8 months, 2 weeks, and 3 days they promise they can finish in 6-12 months. The most important tasks are ordered based on expected value and they are given a deep-er level of estimation. As the team moves forward, value is constantly revisited, task importance is allowed to shift, and only the most important tasks are given enough estimation effort to know when they’ll be done.

Of course, this is an oversimplification. Details belong in a dedicated post, and I’ll do one of those soon.

Estimation is also an important tool outside of planning. When someone from DevOps needs to set up load tests, they’ll estimate the expected load. This isn’t an estimate needed for project planning, but for testing. A developer may estimate some values for an algorithm they are creating to solve a business need.

Estimation is useful on a personal level for everything from planning to easing the cognitive load of making lunch. Estimating what you can get done in a day will allow you to leave room on your schedule for unexpected interruptions. Estimating how much sauce you’re adding to your chili for the team slow cooker partyc an get you out the door faster than exactly measuring it.

Estimation is something we all do, all the time. It’s easier than exact measurement much of the time. Unfortunately, we are bad at it. That, however, is a topic for another day.

Want someone to help you evaluate your current planning or estimation practices? Contact me today for a free consultation. We’ll discover your need and see if we are a fit to work together.

October 21 2014

Thoughts for Estimation Training

AdamM Estimation 0

Balance With Coins Stock Image — digitalart – FreeDigitalPhotos.Net

As I mentioned in my last post I would like to create training. For some reason I feel like Estimation is a decent place to start. I think a one hour online video training session is something I could probably produce. I would also like a longer interactive one of 2-3 hours. I think that is long enough for estimation.

It isn’t long enough for Agile though. The training will come with the assumption that the attendees understand the Agile concept of making decisions and commitments as late as responsible. This will be briefly addressed, but it will not be gone over in-depth. Concepts I hope to cover include reasons for estimation, value versus cost of estimation, when to estimate, estimation techniques, and estimation red flags. The target audience will be teams new to group estimation, new scrum masters, and project managers new to Agile methodologies.

May 13 2014

A Beginner’s Guide to Planning Poker

AdamM Estimation, Training 0

I have written about estimation before. I have written about Planning Poker before. Today I am going to do a simple beginners guide to Planning Poker. The difference is that this guide is meant to be used by you. You could use it as a presentation presenting the idea of Planning Poker. Alternately it can be used to teach a team and run the first session. With that frame of reference in mind let’s get started.

How many of you like to estimate as a team? I do. I find it an easy process with lots of value for everyone involved. What if I taught you a method that will get your team rapidly reaching a consensus while estimating? These estimates will be accurate enough for iteration planning. As a side benefit, the team will have a better understanding of the product and its future direction. The process is lightweight enough to keep the team engaged. The end result is estimation meetings that are not dreaded by anyone.

March 4 2014

Estimation is Dead, Long Live Estimation!

AdamM Estimation 0

Image courtesy of Graeme Weatherston / FreeDigitalPhotos.net.

Estimates are kind of a big deal. I’ve written about them before. (See here.) Last year was a big one for the idea of completely dropping estimation in the greater software development community. In July the twitter account @NoEstimates was taken on as an outlet for Woody Zuill specifically for sparking discussion on this idea. Ask any person in software development what they think of estimation and they’ll share their opinion with you. Mention the idea of not doing any estimation and it could get heated.

The “No Estimates” crowd has some good points. However I believe all out “No Estimation” is gouging out an eye to spite the face. What I feel the right answer is, and the one I have seen from various thought leaders this year, is “Valuable Estimates Only!” It just doesn’t roll of the tongue as well.

November 5 2013

Story Points should not be numbers.

AdamM Estimation 0

Earlier I introduced the concept of Planning Poker for estimation. (Part One. Part Two.) This has continued to be a very good tool for our team, and specifically our project manager. While most notably used for estimation, that is only part of the benefit that is received by using a process similar to Planning Poker. To our team the interaction between the team and the product owner coupled with the team wide understanding of upcoming user stories are bigger benefits.

When I first introduced this new form of estimation to the group I made a mistake. I did explain the concept of story points to the group and even had cards made to represent them. The cards all had graphics backing the central number to help frame them as relative effort. Boxes play heavily into the product we develop, so I had single boxes, groups of boxes, and pallets of boxes for the story points. I also created a separate set of cards for estimating tasks and bugs. They were to be done in hours, so they had cards with numbers and no background. The mistake is that the story points were set up with the same set of values as the hours.

October 8 2013

Original Estimate. Remaining Work. Completed Work.

AdamM Estimation 0

These have been the three most underutilized and ignored fields in our TFS template for over two years. We did an entire application re-write with three major release milestones, multiple integration points, and multiple small maintenance releases hardly acknowledging these fields. What little estimation data the project manager received was from one person on the team. Actual information was never fed back in. Estimations were broken. It was increasingly difficult for the project manager to reliably communicate with the business what the team could accomplish at what time. This was the biggest pain point we could identify.

Our bottom up approach to Agile implementation started here. As long as upper management received time based estimates on features for Enterprise planning purposes they were not especially concerned with where they came from. They cared only for how accurate we felt they were and how accurate they ended up being. That mindset allows us to change our estimation methods with little fear of interference. This is likely a common state for a project team to be in.

September 24 2013

Estimation is hard. Part Two.

AdamM Estimation 0

I covered the three main reasons I use Planning Poker last week. This week is about how planning poker plays out in an estimation meeting.

The best way I can think of to see how planning poker works is to show it. The estimation will be for a trip from Minneapolis to Chicago. The Product Owner has called her group of developers together to provide an estimate for the customer. The developers are all the people who will do the work on the trip. An analyst might be used to better define the trip parameters. A developer may be used to build the trip based on the parameters, but usually there will be more than one. Someone else may be testing a model of the trip to ensure it satisfies all parameters to the best of the teams ability. The people involved may or may not know a lot about the other roles present. For this exercise the important thing is that each person doing work for the requirement is present to estimate it.

September 17 2013

Estimation is hard. Part One.

AdamM Estimation 0

How long does it take to travel from Minneapolis to Chicago?

Give a group of ten people this question and ten answers will come back. Some may be radically different. People have a lot of trouble estimating how long something will take, or how big something is. I see this in my own life on almost a daily basis. How long will it take to change the brakes on the car? On the van? Cook dinner? Each time I think it will take a different amount of time, and each time it does – but I am still wrong about how long.

This is a problem when a business is trying to plan enhancements and future projects. The good news is that while we are bad at straight time estimation, we are usually pretty good at relative estimation. The brakes on the van will take a little longer than on the car due to the size difference of the vehicles. Dinner today will be quicker than yesterday’s because of the dishes I am making. A trip to Chicago might take twice as long as a trip to Ames, but it could be half the time as well.