This article was written in 2014 by Antoine Lafontaine who was JM’s colleague at the time in a web development agency. The article introduces the complex topic of estimating with points associated with agile software development. Because the article is no longer available on the web, we decided to post it again here because of it’s excellent pedagogical value.

I’ve recently been wondering how I could better convey the value and merits of story points versus man-hours estimates. I hold the belief that points estimates are a very valuable tool for development teams. My understanding of its usage may not be as obvious as I personally came to feel about it.

I was first coached in Agile development at a Tokyo-based start-up. Our team consisted of 6 permanent, well-rounded developers, 2 contract developers and a process consultant/interim CTO. The person had been hired to help us improve our infrastructure and release processes, as our recent pushes to production had been quite bumpy.

At the time I had been avidly reading about Agile development, out of personal curiosity. I had started discussing the approach with other team members, thinking we’d gain much by using some, if not all, of the techniques prescribed in the O’Reilly XP book - The Art of Agile Development. I had no hands-on Agile experience at the time, and I was looking for other partners to share the risk of experimenting and promoting the idea to management and other stakeholders.

There are moments where things in life align in such a way that you feel you’re in the right place at the right moment. That new consultant coming to Tokyo and becoming our Agile coach is one of those moment in my life. It still shapes my personal beliefs and professional ethics to this day.

A fairly common practice in web development projects is to estimate the work we’re being asked to do, so it can be broken down into actionable units. In Agile projects (Scrum-based, in our case), we call those actionable units User Stories.

Most activities during an Agile project revolve around these stories. The first technique taught to our team was estimation poker, for estimating the size of each User Story. Team members were given cards with various point-values assigned, in a roughly exponential scale (1,2,3,5,8,13,20,40). Each team member chose a card that seemed an appropriate effort estimate for the said story, with all cards revealed in unison. If all the point-values (e.g. cards) were in agreement, the estimate was done. If they were not in agreement, a discussion ensued, then another round of poker. Consensus tended to emerge after 2–3 rounds. There are other ways to get to a points consensus other than playing estimation poker, but this was a useful exercise to generate discussion of assumptions and to reach consensus. It was also meant to induce a fundamental change in the way we were thinking about estimates, driving us to the story point approach.

A fairly common pitfall I’ve observed in many Agile organizations is the use of hours-based estimates instead of “unit-less” points-based systems. I think this is because there is a tendency to associate 1 point to one hour, failing to understand the value provided by unit-less point estimates.

Now, time for the hot-dogs 
Say you sell hot-dogs and a client asks how much time it will take to make one hot dog. Let’s assume you’d say 5 minutes if you want it toasted, but 30 seconds if you’re fine with a steamed one using the microwave. After hearing your answer, the client tells you he’ll take a hundred (100) toasted and he’ll be back in eight (8) and a half hours (500min/60 = 8.33hours) to pick up his order. Responsibly, you’d have to interject and say that you won’t be able to deliver on that request, since you’d need to go get more sausages and bread; plus you’d need to make sure some of the order was delivered at intervals, to ensure the hot-dogs were still at least warm for whomever would be eating them. So how much time would making a hot-dog take now? “Well, still 5 minutes, but…”

Now let’s imagine you’re in the restaurant business and are aiming to be throned the “Hot-dog Queen” by all other street vendors in your region. You assemble a team of top chefs to try to come up with new amazing hot-dog recipes; ones that will ensure you build the reputation your business deserves. The team sits down and starts discussing all the fancy ideas, writing them on cards. After some very heated debates on how awesome the “Fala-dog” would be and how you’d surely save the planet, you stop your team and ask them to start sorting the cards together side by side on the table from the easiest to create up to the most complicated one. You then assign 1 point to the easiest, 2 to the recipe next to it and continue until you’ve put all the recipes under one of all the numbers you are using for your effort scale (1,2,3,5,8,13,20,40). Now you ask your team how many of those new recipe can we try to create for next week (for a taste-test party). Without committing to exact hours per recipe, the team can get a sense of what set of easy, medium and complex recipes can be tackled in the given timeframe.

Although these are fairly convoluted and incomplete examples, I still hope they convey what we, as developers, often feel when we’re sitting down in a meeting and trying to come up with estimates.

I think that by using points we gain two major and subtle, yet very important benefits:

1. All people at the table are able to participate in the estimation process, notwithstanding their level of experience or expertise. As long as they are able to listen to the conversation and have some idea of how relatively complex a thing is relative to another, they can give and share their opinion and propose a possible effort estimate. With hours, a non-technical person has no basis for giving her opinion on a story when it comes to estimates. This also applies to having less experienced developers estimate with more experienced ones; or topic-area experts with generalists.

2. Giving a time estimate is often taken as a commitment to provide the story in the given estimated time or less. Even if there’s some agreement in a team that nobody will be held to meet those criteria (that those are “just estimates”), developers will often struggle, even unconsciously, to meet those hours estimates. Using points supports the tacit agreement that estimates are to be used to help guide how much we can expect to deliver while not being tied to a specific time it will actually take to get these delivered. This removes some of the mental burden imposed on the developers by hours estimates, and allows for variability in conditions, hiccups, roadblocks, etc.

One key point is that Agile development is based on trusting the development team and in promising the product owner that this trust will translate in a steady predictable stream of valuable output.

Also, if hours are required at any level of the organization that’s pondering if moving from man-hours based estimate to points-only estimates would make it impossible to figure out hours needed for billing, for example, it is always possible to devise some method to derive man-hours from historical point estimates against time spent on a sprint. (This alone would be a full topic for another post!)

In conclusion 
Time-based estimates may be invaluable to drive a business successfully at the business and reporting level, but the context of the development team and what is most effective there needs to be considered. In many cases, unit-less points-based estimates add significant value to the estimation and delivery approach. They can be an underestimated ally and performance driver for a team.