Alternatives to estimating in hours/story points

Question

We are looking to change our approach on estimates. Now we estimate in hours/days, but we would like to change this and make our process more flexible. We are working based on Scrum, where stories are planned based on an initial estimate and after the technical analysis, a new estimate can be used (which is more refined).

Because we noticed that our estimation process can be improved, we are looking for alternatives. I already found documentation online about using story points and velocity to indicate the effort required to implement something.

Are there any alternatives besides story points / velocity? I have been looking online, but I fail to find good sources with alternatives.

Answer 1

To me it sounds like you want to improve your estimation accuracy - not making you more flexible. So here are a few pointers.

Cone of Uncertainty

The earlier in the project you are the less accurate your estimate is going to be. The cone of uncertainty illustrates this by starting at a spread of 0.25x to 4x and slowly converging to the factor of 1. This is the maximum accuracy you can expect from your estimates. Ie. when you first start out you cannot be more accurate with your estimate - you can only be more lucky.

I bring this up because your questions sounds to me like you are prioritizing stories based on the initial estimate, without taking into account any refinement. I might be wrong about this though.

Ranges trump single guesses

Instead of providing single point estimates, offer ranges. Start by estimating the absolute worst case scenario for your upper bound. Then estimate the "likely" scenario for your lower bound. Try to set both estimates so that you have have 90% confidence of being right. This does two things: Considering the worst case first puts your mind on the track of what can go wrong and keeps you from ingoring too many risks. Second by forcing yourself to expand your estimates to an extreme 90% confidence range you'll at least getting something of a 30% chance of being right.

Relative estimates

Whenever possible try to avoid making absolute estimates and try to estimate items in relation to each other. Then use velocity to put the amount of completed stuff per sprint in relation to the estimates you put on it. You CAN do this with hours if you want. It just comes more naturally if you do it with points. Also in order to retain any degree of reliability you must refrain from changing your relative weights. If you estimate your first sprint on the basis that Task X is Y hours/points and then after the sprint look at your velocity and say "Aha! We were off by a factor of 2.375 let's keep this in mind for future estimating" you're shooting yourself in the foot.

Just answer the question already!

There are essentially three approaches you can take when you need to move a pile of rocks:

• Estimate the true weight of every stone and accept that you suck at those guesses. Also accept that people have silly tendencies such as expecting they should be able to carry a stone of a certain size, or not wanting to look weak by estimating a stone at too high a weight to argue that the can't carry it.
• Estimate your stones relative to each other. Accept that your estimates are not much of an indicator of how much work it is to clear the entire pile until you've started to work on it.
• Don't estimate the weight of the stones. Since everything above means that you're so unlikely to be anywhere close to the real number you instead focus on breaking every rock down to handy sizes (as you have to anyway) and realize that as your stones become more homogenous in size the less difference there is between estimating each of them and simply counting them.

Answer 2

Montecarlo simulations.

The idea's pretty simple. Your stories over the previous weeks will have some kind of distribution as to how long they each took. Let's say that the stories took this number of days each until the next story was finished:

3, 2, 5, 4, 1, 2, 3, 10, ...

These often follow something called a Weibull distribution, which is skewed towards a big, fat tail since most discoveries slow you down more than they speed you up. (Human intuition tends to assume a normal distribution, which is one of the reasons we're usually optimistic.)

Sometimes though these distributions are bimodal (there's some legacy system that slows down every story that touches it, for instance) or just plain messy (nobody checks in on a Friday because they don't want to break the build). The good thing about Montecarlo simulations is... it doesn't matter! It works regardless of what your distribution is.

The way you do it is to calculate a random journey through the stories you have left, and find when that journey finishes. So let's say I reckon I have 60 stories left. For each story, I'm going to pick how long it took between stories randomly from your distribution.

1, 5, 4, 10, 3, 2, 10, 2, 5...

And you keep doing this until all 60 stories are done. Now add the number of days it took to the starting date...

...and then do it again.

Do it 1000 times or more (yes, you'll need software for this, or a specialized spreadsheet). It doesn't matter if that weird "10" gets picked twice because that won't happen for every journey; some will be strangely slow, but most will be faster. Record the end-dates for each journey.

Now you have something more than an estimate. You have a probabalistic forecast. So if I start on 1st January 2018, I might get something like:

100%    10-04-2018
95%     03-04-2018
90%     29-03-2018
85%     25-03-2018

etc.

Each one of those dates shows what percentage of the journeys you took finished by that date. This gives you an idea of the probability of hitting any given date with all the stories. Alternatively, you can see how many stories you get done by a given date, just counting until the date is reached.

Most people are really optimistic when they estimate, and you're lucky if you even hit 50% of journeys finishing by that date!

Troy Magennis of Focused Objective has free spreadsheets for things like this, and Dan Vacanti at Actionable Agile's tool is cheap enough and IMO excellent. Both of them also have numerous videos talking about the technique. I also have an open source project that has no validation yet but works well enough for importing Excel spreadsheets, including exports from Jira.

Troy recommends between 7 and 25 weeks' worth of data to get this to work; more than that is usually out-of-date. Do bear seasonal patterns in mind, though.

Probabalistic Estimates

If you don't want to go through the hassle of Montecarlo, but you do want the probability distribution, a technique I learned from Douglas Hubbard, author of "How to measure anything", might help you.

I ask the team to give me an idea of when they think they'll ship. Usually they'll be really optimistic, so if it's early January they'll say "End of April", or something like that.

Then I ask them how likely they are to ship then. "Oh, 70%," they tell me.

So I offer them a hypothetical prize of £10,000 and two different ways to win it. They can either choose a red marble from a bag containing 7 red and 3 white marbles, or they can ship by the end of April.

They usually go for the marbles; despite saying they're 70% certain to ship, they prefer the chances of drawing 7 out of 10 marbles!

So we reduce the number of marbles in our hypothetical bag until they prefer to ship. That tells us what their real confidence levels are. By doing this with different numbers of marbles, we can get a range of different confidence levels.

How to use these

If you're dependent on the shipping date in any way, don't use anything less than 85% confidence. That's usually way out compared to most people's estimates. As the date gets closer you'll be able to see if you're going to make it or not, and you will still have a chance to expedite things or shift other dependencies if required.

Note that the business will not be happy... until they start seeing the time saved by not estimating in easily-gameable story points, and by not having to redo a ton of plans based on something that was never going to happen anyway. You might need to do a bit of education or navigate tricky politics until they accept reality.

Answer 3

No Estimates

There is a fairly strong movements against the creation of estimates. Contrary to the name, this doesn't mean no estimating, just that you don't create and publish estimates.

How It Works

First, the team should settle on an "averaged" sized story. You'd use a guideline like "We should be able to do 5 - 8 of these stories in a sprint." It helps to have 2 or 3 examples of past items that are around this size.

Now that you have a rough target size, you break down items that are bigger than that until they match near the size. The idea here is that this processes of estimating to size will drive out the beneficial conversations in the team that creating estimates does, but since there are no resulting estimate numbers, it avoids many of the dysfunctions and problems than can come from publishing estimates.

The good news for Product Owners and stakeholders is that forecasting is still easy. If the team is completing 5 - 8 backlog items per sprint on average, you can take a good guess at how many sprints it will take to get to a certain spot in the backlog.

Answer 4

Function Points (FP) is a good unit of measure for software output

If you are practicing Scrum, you should go with story points. The reasons are:

1. Time-based estimates (such as hours) give a false impression of accuracy and predictability to people outside of the team, especially senior management.
2. People are better at relative estimation (story points) than at absolute estimation (such as hours).

Having said that, let me try to answer your question:

Now we estimate in hours/days, but we would like to change this... Are there any alternatives besides story points / velocity?

In mature industries, high-level estimates are made based on output:

• You can get an estimate for how much an office building will cost per square foot.
• You can get an estimate for how much a unit of energy will cost for a power utility.

Even though Scrum Guide doesn't mention story points, Jeff Sutherland, the co-founder of Scrum is a big proponent of story points. One of the biggest weaknesses of Scrum is that there are some unit of measures for the effort input, but there isn't a unit of measure for the result output.

There are well established organizations, standards, tools and certifications for Function Point, which is a measure of the output:

• Organizations: in the US, it is the IFPUG International Function Point Users Group and in Europe NESMA and FISMA Finnish Software Measurement Association.

• Standards: You can see the ISO/IEC standards listed in the Wikipedia Function Point page.

• Tools: There are some tools available to automate FP counting to some extent.
• Certification: IFPUG offers Certified Function Point Practitioner (CFPP) / Certified Function Point Specialist (CFPS), for example and there are others.

Answer 5

Decide What You're Measuring

Are there any alternatives besides story points / velocity?

You can estimate in any unit you plan to measure. Common measurements include time, effort, money, and calendar-based targets.

• "Hours" are a form of time-based estimation.
• "Story points" are a form of effort-based estimation focused on relative sizing.
• "Velocity" is a form of trend-based tracking & estimation, and is primarily an aid to release planning.

The three vertices of the iconic project management "iron triangle" are scope, schedule, and resources. All project controls and estimation techniques ought to express one or more of these items, or the relationships between them.

Alternatives to Time/Effort

Most projects estimate all three vertices, but the basic theory of modern project management is that you can only control for any two of the three. You can't fix scope, schedule, and resources simultaneously; at least one of the three needs to flex.

For example, you could estimate a project in resources and schedule in order to arrive at scope. You could also estimate scope and schedule to arrive at resources. In general, though, business is most often concerned with when a project can be delivered, so time and effort often make the most sense as primary estimation techniques. That doesn't mean they're the only approach, though.

Some queue- or cycle-based methodologies don't entail unit-based estimation at all. For example, while Kanban often provides many metrics that can be useful for tracking, release planning, and process improvement, individual work items are never explicitly estimated.

Various types of work (e.g. support or maintenance) are often unestimated at the unit level as well. You might express such work as a queue, a circular buffer, or a bucket, but ultimately these are all just ways to plan or budget work at the macro level rather than at the unit-of-work level.

Parting Thoughts

If you want to avoid estimates altogether, you might look at the #NoEstimates movement. However, Ron Jeffries has some interesting thoughts on that, which I think are required reading before you jump on that particular bandwagon.

You have to evaluate and control your project within some basic parameters, and time & effort are two of the most common. If you want to move away from estimating man-hours or level-of-effort, you certainly can. However, I'd spend some time carefully evaluating your business case for doing so. That might help you discover a better metric, or help you uncover an X/Y problem that is driving the search for an alternative. Either way, taking the time to introspect your assumptions and your process is generally time well spent!

Answer 6

To the best of my knowledge, 'no'.

Time estimates are the intuitive method of estimation. Managers want to know how long X will take. Intuitive solution? Ask how long X will take.

There are, however, problems with this approach. For one thing, the time needed to accomplish X will vary depending on who completes X. For another, humans are bad at estimating in time. So story points, a form of estimating in relative effort, came about. They have since been found to be far for accurate. They can be converted to time via applying the Team's velocity.

I don't believe there is another method, primarily because I don't see what else could be reliably used. I also don't see the need. If you need to define a process quickly and don't want to/can't spend time to think it over, estimate in time. If you want a more accurate method, use story points.

Edit: At the time of writing I'd forgotten about the 'no estimates' method. Though technically one could say that such a method is the same as story points, only every task is given the same effort. There could even be a continuum, with approaches such as where every task is estimated the same except for rare outliers. This is the approach my last Team evolved into - nearly every Story was 1 point, with the occasional 0.1- or 3-point Story.