Estimations

This post is about dreaded estimations. Let’s think about why we do them, what problems they bring to the table and what the Agile estimation approach is in comparison to other approaches.

What will you do with those estimations?

Whenever I hear people say that they need to estimate these or those stories, I first reply why they “need” to do it in the first place. What will they do with those estimations? Answers vary. “I don't know”, “it was asked”, “there’s a spreadsheet to fill” or “it’s the way we do things here”. These don’t quite seem like good answers, do they? Some others tell me they aren’t sure, but the conversation held in the process is really helpful. Although this is true, you don’t need to estimate stories to have these conversations, right? The most common answer is they need to know what to assign to an iteration. Do you really need to have estimates to do this? Can’t you just do it by gut feeling? After all, the purpose of iterations is managing complexity by focusing on a small part of the system. You don't need to estimate a whole backlog to do that.

Of course there may be legitimate reasons to estimate. Entrepreneurs with their first investment need to know if the money they have will be enough to build the first experiment. Companies need to know how much money they need to invest in a new product or feature to decide if it’s worth. If there are multiple options, the cost is one of the factors to consider. Companies also need to organize their people and resources. They need to synchronize. They need to coordinate dependencies. Knowing how big projects (or tasks) are, how long they will take and which resources are needed is useful information, right?

Ok, there could be valid reasons. Does the team know about them? Are we really using these estimations for something that we think is a legitimate reason? Do we all agree these estimates are providing valuable information? Are we using them correctly? It is really important that we answer yes to all of these questions. Let’s take a look at some of the problems that estimations may trigger.

What can go really wrong with estimations?
We all know the problems that estimations bring to the table, right?

• First, they take time. Precious time you are not using to produce anything valuable (in lean terms, they are waste). Even worse, spending more time doing them doesn´t necessarily mean more accuracy.
• They are really difficult to make and they are usually wrong. The accidental complexity lying in most organizations is not taken into account. There are meetings, holidays, people feeling sick, dependencies, you name it. Anyone who has worked in a big organization knows that. And… People work on multiple things, even multiple projects. Although we all know about Little’s Law, few apply it.
• They are taken as commitments. With these estimations, created with unknowns and uncertainties, a release date is fixed and communicated. From then on, the team knows that extending that date will be ´deviating´ (I hate this word!) from the original plan, even when everybody also knows the new work discovered (I refuse to call these change requests or scope creep). To deal with this, experienced managers know they need to add a buffer. However, is this really healthy? My opinion is that with a really collaborative team, you shouldn’t have to do it. You are giving the people that use this information an inflated cost and the team a license to take more time.
• When the release date is approaching and pressure grows, these (innocuous) estimations trigger the worst dysfunctions. The first thing that drops is quality, as there is no time to test or refactor. Additionally, people start working longer hours, they are tired -if not burned out- and introduce more bugs. These problems may undermine a team. Distrust sprouts from the soil, business and tech teams break apart, work is not sustainable and change is not embraced anymore. Those are the times when you realized you made a mistake estimating.

Estimations before Agility

Many years ago, when the default process was Waterfall, people used to work in (very) big projects. I’m talking about projects that extended over several months or even years. These projects were subdivided in ‘activities’ which didn’t add any value per se (e.g. analysis, design, etc.). To understand ‘progress’ and dependencies, we estimated these activities and used Gantt charts to visualize them.

Estimations on this approach were of utmost importance. Delays on each activity were really harmful as they impacted all dependent activities. We needed to get better at estimating (as if it were really possible). There’s a lot of information about these problems in Cohn’s Agile Estimating and Planning if you are interested. I don’t think the problem was relying on estimations too much. The whole approach was very risky. We were trying to predict the future and we couldn’t. We were working on very big projects where all value was going to be seen in the end without involving business users in the construction. No, probably estimations were not the problem.

The Agile approach

The Agile approach to building software recognizes the uncertainty and the risk and manages these in an entirely different way. Recognizing you can’t predict the future makes us work on smaller, prioritized projects (I’d like to call them experiments). Experiments that lasted years now last months or, even better, weeks. Estimating smaller experiments is always more accurate. These experiments, in turn, are subdivided into items that are prioritized and then built according to the team’s definition of done. We estimate these items, usually called user stories to have an idea of how long the experiment is going to take and to track it while we are working through it. Estimating these really small items should be even more accurate. More importantly, if these items are small enough, do we really need to estimate them? As the project progresses, we make our progress visible, which allows us to understand better when we will finish. From the beginning we have understood they were estimates and we update them as we learn.

What I just mentioned are the aspects that, in my opinion, make the Agile estimation approach.

In summary:

• Estimating small prioritized and valuable pieces of software
• Don’t waste a great deal of time. Update the estimation as you learn.
• Don’t treat them as compromises. They should never harm collaboration.

Relative estimations with story points

“I like to say that I may have invented story points, and if I did, I’m sorry now. Let’s explore my current thinking on story points. At least one of us is interested in what I think.”
Ron Jeffries

Let’s talk a bit about relative estimations and story points, considered for many years the de facto agile estimation technique. I found out recently that Ron created the now very famous but little understood story points. For ‘young’ people like me that started using Agile after 2005, we got to know them through Mike Cohn via his Agile Estimating and Planning book.

The rationale behind them is that we are better at making relative estimations than absolute ones. An additional advantage is that they don’t leave room for (management) pressure as we estimate how big or small something is compared to another thing.

After comparing stories, we assign story points that describe this comparison. This way, if a story has 2 story points it will require double effort than one that has 1 story points assigned and ⅔ of a third one with 3. These story points amalgamate all factors that contribute to the effort:

• The amount of work
• The complexity
• The uncertainty and risk
  Note that we use a discrete scale for story points. The reason is that we assume it’s difficult and there’s uncertainty. Trying to be more accurate doesn’t make sense. Fibonacci became very popular, but it can be any discrete scale. The estimation is performed by the whole team, usually doing Planning Poker. It is important to stress that what we are deciding, as a team, how big something is related to something else, considering all work needed to complete this story (in other words, complying with the team’s definition of done).

After assigning story points to our stories, we can start measuring how long they actually take. Usually, this is done measuring the team’s Velocity. Based on their velocity, a team can forecast their capacity and their possible (range of dates) for completion. Does this work? Opinions vary. I believe in the sweet spot -with a stable, collaborative team- it does.

Were our problems solved with this approach?

By reading posts of different authors and talking to colleagues, it doesn't seem so. My own experience tells me that in most places, managers need completion dates and they don't want to deviate from them. Tech teams still have a lot of pressure on their release dates. Story points are not understood or they are understood in different ways. Usually, they are translated to units of time immediately or used to compare teams. Increasing the velocity is as easy as starting to assign more points to the stories. This post by Joshua Kerievsky, although a bit old, describes problems I still see all the time.

What if we don't use story points?

In Joshua’s post, he mentions Dan Well proposed (in the early 2000!) breaking the work into small items of similar size. The number of items finished in the iteration becomes the velocity. Forecasting an end date based on this velocity is also trivial. No estimations needed.

Another option mentioned in the same post is estimating in team weeks (0.5, 1, 2 and 3) and doing frequent re-estimation. In this approach, the team estimates how long it would take them (no matter how many of them work on each story) to complete each one. Every couple of weeks, they re-estimate the remaining work. Josh states this approach gives management what they need: a decent way to predict the scope, schedule and cost of a release.

Finally, there’s people that suggest avoiding estimations altogether (#noestimates movement). Instead of wasting time estimating, focus on a really small experiment, do a really small release and keep iterating. Forecast based on this. Not bad, right?

What’s great about this post is that demistifies story points and encourages us to explore alternative methods. We don’t need to use story points to do relative estimations. We don’t need to use relative estimations to do Agile estimations. And we don’t even need to do estimations to do Agile.

Final tips

Before estimating, make sure there is a legitimate reason. Also make sure everyone understands they are estimates and they have a certain amount of uncertainty. Also, (try to) make sure that managers won’t ever use these estimates to pressure the team.

Make the ‘estimatable’ item as small as possible. If it’s an MVP, determine which is the smallest useful experiment (most of the time, this is bigger than necessary). Use the idea mentioned in Josh’s post of embryonic version (the idea is great as it makes the MVP smaller and it allows you to manage expectations better). If you are estimating features, try also to break it into the basic (smallest) version and the extended one. Ship early, ship often and you will need less estimations (continuous delivery of the most valuable features doesn’t need estimations, right?).

While tracking the project, maintain as much visibility as possible. Re-estimate with the team often. Make sure that the dates you are aiming for always seem reasonable.

Finally, don’t ever let estimates get in the way of having a healthy, trustworthy team. Remember, when business people don’t collaborate with tech people, when there is unreasonable pressure and we just think about dates, the worst dysfunctions arise.

^[https://ronjeffries.com/articles/019-01ff/story-points/Index.html]

Do you want to know more about the organization in 10Pines?

We have a culture web site that we recommend you to read. http://culture.10pines.com/

We wrote a similar post to this one and maybe you’d like to read it:

https://blog.10pines.com/2014/03/21/rethinking-estimations/

You can apply the agile tag filter in our blog to get the related articles: https://blog.10pines.com/tag/agile/

If you have any questions feel free to contact us through our social networks. Sometimes it may take us a little time to respond (because we have a lot of day to day responsibilities) but we eventually do it.