Agile: planning part 1. Hours versus story points

After I prepared a post about agile planning, I found out the post was becoming huge, so I divided it into three posts:

1. Estimating
2. Short term planning
3. Long term planning

This first part is about estimating user stories, adding to the debate of hours versus story points.

A lot of project managers who are involved in agile projects see a story point as a measure of time, often using the equation “1 story point = 1 hour”, while on the other hand an agile method like scrum teaches us story points are a measure of effort or complexity, and are at most loosely coupled with time.

So should we estimate using hours or estimate using story points?

Let’s first build the case for using story points: It is very hard to estimate how long something should take, but it is less hard to estimate whether something will take more time or less time compared to something you know well. To aid the estimating process scrum introduced story points. Story points aren’t a measure of time, but are a measure of the relative effort it takes to get a job done. I use the word “effort” as a container for “complexity”, “uncertainty”, “amount of work” and other factors influencing the, well, effort, it takes to get the job done.

To start the estimating process, you first establish a baseline, by choosing several well-known activities, and assigning points to those activities. One way to do that is to have a set of stories each worth 1 story point, have a set of stories each worth 3 story points, and have a set of stories each worth 8 story points.Then, when you start estimating new user stories, you compare them against user stories from those baseline, to quickly get a feeling on how much effort is required to finish the user story.

This estimating is done using planning poker. During planning poker, each team member estimates the number of story points a user story is worth, and all team members show their estimate at the same time. If there are differences in the estimates, then team members should explain why they think this user story is worth a lot of story points (or not). Those explanations and resulting discussions will lead to a better understanding of the user story. Team members then poker the same user story again, where the estimates are probably more converged now. If the estimates still are not converged enough, then there is more explaining and discussion to do.

Using story points has several advantages:

• A skilled senior developer will probably be a lot faster than a junior developer. If you’d use hours, the senior might estimate it would take him 4 hours to do a user story, while the junior would estimate 10 hours, which could lead to discussions about how fast you can do something instead of focusing on the complexities of the actual user story. By using story points the effort however is relative to the baseline, so the junior and the senior can still have a meaningful discussion about the effort, and agree on the relative effort.
• No matter what people say, it is really hard to estimate time. By explicitly not using time, you don’t give a false sense of certainty. Because as soon as you carefully say “I think it might take 8 hours”, people will take it as a given that you’ll be done by the next business day and count on it, and before you know it you’ll be doing unpaid overtime to keep a promise you didn’t make! Estimating a user story is hard, and it is exponentially more difficult to estimate a whole project. It would be good if more and more people understand that a project is a process in which you work towards a product vision, instead of it being a meticulously defined path working towards a completely specified goal. Because the latter is simply impossible. Moving away from the “time” concept helps a bit towards that understanding.

It also has some disadvantages, of which I’ll list the (for me) biggest disadvantage:

• If you use story points then for the outside world the velocity is the measure of output of the team. What further happens under the hood of the team is invisible. This “shielding” of the team is an advantage, since you don’t have to explain hours spent on for example technical debt, research & development, maybe some contribution to an open source project, and other stuff to keep the team healthy. It is a slippery slope however, since it is also tempting to “quickly fix a left-over from last sprint” or do to some operations work under the radar, etcetera; as long as you do your average amount of story points per sprint everybody is happy. Eventually this may lead to for example 60% of the capacity being spent on Scrum, while 40% of the capacity is unmanaged and escaping continuous improvement, and could eventually turn into an inexplicable resource hog. This is especially tricky in DevOps and BizDevOps teams.

How about estimating using hours instead of story points?

It is very hard to estimate how long something should take. However since people are paid by the hour there is always pressure to convert story points into time to be able to subsequently be converted into money. If you use hours, you lose the advantage of relative estimation, so you could end up having fruitless discussions about who can do what faster. However if you use hours, with the right guidance, that can be turned into very fruitful discussions on what takes how much time, leading to valuable insights:

• It becomes clear who can do what efficiently. So if someone is very fast at performing some task, such as parsing texts, there is no need to sweep that performance difference under the rug. Let the fast developer do the task! Or, double the amount of hours and let the fast developer do the task and let someone else watch and learn. Or add a user story in which the fast developer gives a masterclass to her coworkers on how you can parse texts using regular expressions to save a lot of coding logic.Or, if someone for example consistently estimates high on the documentation part, maybe it would help if that team member takes a course in technical writing. Or perhaps somebody already knows a lot about a certain topic; add an hour to the user story so that team member can quickly write a brain-dump about the topic to help the engineer that will actually work on the user story.
• Mentally most engineers will, also when estimating relatively, divide the work into separate tasks (such as coding, testing, documentation, some research, etc). If you make those hours visible, then you can have meaningful insights in the time it costs to do things. If testing for example is only taking 10% of your user-story time while documentation takes 20% of the time, then it would be best to first focus on making the documentation process lighter or more efficient, before you start fine-tuning your testing tools to maybe gain 1% of time.
• If, when closing a user story, you write an approximation of the hours spent on the user story, then that also gives valuable data for a retrospective if you then zoom in on questions like “why did things take longer or shorter than estimated?” which will lead to increasingly better time estimating skills.
• Using hours and trying to account for most hours will also make waste painfully obvious. If someone for example plans a meeting of 2 hours requesting 5 people to be present, then including preparation time etcetera that will be a user story of a whopping 13 hours. Is that meeting really that valuable to spend 13 hours on, and if so, perhaps there is a way to make the meeting more efficient?

There is a pitfall though; we really don’t want to move backwards to a system where every hour needs to be accounted for, since writing down hours-spent costs time and breeds frustration (unless you’re a lawyer making $600 an hour, then I can imagine it is a rewarding activity). There however is a fairly large amount of slack hours; make those hours visible and “give” those hours to the team members. It feels cool and rewarding for engineers to officially be able to spend 20% of their time on whatever they want. If you don’t officially give them those slack hours then they will also spend 20% of their time doing what they want anyway, but then won’t feel good about it. :)

That 20% “slack time” can by the way be very valuable. People need time to think about new and exciting stuff and do some research and playing around. After all, we don’t want the below situation to occur, where everybody is working really hard but is not keeping up with modern technology:

Some comments if you estimate in hours:

• When estimating, start by using “engineering hours”. “Engineering hours” are hours where the engineer is undisturbed and is in his or her happy flow and cranking out code. Generally this is the time a lot of engineers think in anyway. Starting from that time, build in uncertainties, bad days, and user-story specific activities such as testing, documenting, deploying, monitoring, and many other things. Using a checklist would be useful.
• Still allow for fuzziness; so you can still use the Fibonacci sequence; the higher number you get, the lower is the accuracy of the estimate. Because it remains an estimate!
• To stress that again, it remains an estimate, and estimating in hours should be seen as a tool to aid continuous improvement, reducing time-consuming waste, and to be able to plan a sprint that can be finished in time. An estimate is not a contract! It is in that sense no different to estimating using story points, so if a user story takes less time than planned, don't take a break for the rest of the time. And if it takes more time than planned, don't put in overtime but resolve it in another way, starting with discussing your impediment with a team member.

So, hours or story points; I think there are use cases for both. Personally I favor hours, but whatever you choose, choose it for a reason. Agile isn’t about one-liners or following dogmas. Agile is about people focus, reducing waste (maximize the amount of work not done), short development cycles (to always have a working product), continuous improvement, etc. As long as you focus on those aspects, it doesn’t matter an awful lot if you estimate using hours or story points.

Just my 2 story points cents on this subject.

--
Kenneth van Grinsven

[This article was previously posted on LinkedIn Pulse]