Planning Poker: Why Points, not hours

Many Scrum teams struggle with Planning Poker and it's proper use. A recurring question is: "Can't we just use hours instead?". A mistake some teams make is converting the Points back into Man-Days.

The purpose of Planning Poker

Sprint Planning should contain a C-C-C process (Card, Conversation, Confirmation). In brief: 

1 - the PO displays what they want

2 - the team can probe whether they understand the idea in the same way

3 - the team discusses how they want to approach the topic,

4 - Everyone agrees that this is what will be done.

5 - Rinse, repeat until the team decides their capacity is reached.

Estimation in Story Points is used to quantify complexity of the task. It is actually expected that estimates vary until the team has reached a certain agreement on the complexity. 

Disregarding the accuracy of an estimate, a precise discussion of the factors contributing to complexity will bring the team's estimates closer to each other.

An example dialogue during Planning Poker

The Product Owner introduces the new Widget that will shoot our sales through the roof. Tim estimated a 20, Jane estimated a 3. Jane reasons: "All we need is to build some plastic device, put a chip on it and contact our service URL."

Tim then turns to the PO, "So, you expect the Widget to be usable from anywhere?" - "Yup" - "Even when no Wi-Fi is available?" - "Yup." - "Can we build a first version assuming Wi-Fi is present?" - "Yup." - the precision increased, but the Story has already been split into two pieces. Also, everyone on the team now understands why Tim had serious reservations about the complexity of the issue.

While Tim may now agree with Jane regarding the estimate for the first version, Jane may now also have serious reservations about the second stage, because nobody knows how complex this issue gets if "everywhere" also includes underground, in the absence of cellular and satellite signals.

Estimation is for Innovation

One of the first things which classic project managers must get used to is the idea that software development, as the name indicates, is development. Development is not just working according to plan, but the creation of something which was not in existence before. 

Software is always new: If we use something existing, we simply buy and/or include it. But we don't build it. If we build it, it's new. This means, nobody has done it before - or, at least, not exactly in the same way that we need it. 

How can you know how long something takes that nobody has done before?

You can't - and this is why at best, we estimate, not a detailed forecast.

Let's estimate

To give you some understanding of the difference between an estimate and the quantification of an effort forecast, let's play a game.

As a Product Owner, I have great visions and would ask you to do some estimation for me.

Here are 5 items which will bring great value to mankind:

• Cure for Cancer
• Immortalism
• Cold Fusion
• Warp Engine
• Terraforming

Now, I would like you to estimate these items for me. You can probably come up with a numbering between 1 and 20 for these items, where "1" is the least complex and "20" the most complex issue.

Almost intuitively, your numbering approach will probably revolve mostly about your understanding of the domain as well as the uncertainty you have. The actual "work to do" will probably play a miniscule role.

Estimates are not Man-Days

Can you now assign hours/months/years to each of these items?

In principle, the problem is identical to Software Development: We may have a certain (hopefully, more intricate) understanding of the domain, but we have never done that exactly same thing before. 

We will not know which solution is correct until the solution is correct and in place.  

Since the course of action is prone to change due to any new information we gain while we are working, it makes little sense to plan a specific course of action. Every step depends on the last step taken, and every result either encourages or discourages the next step we had in mind. Sometimes, next steps only become obvious once a specific result has been obtained.

Summary

The purpose of Planning Poker is the facilitation of discussion about complexity and uncertainty. We care for having a common understanding and dealing with the "known unknown". Removing any last bit of uncertainty about the issue might require more effort than actually coming up with a working solution, so we simply accept this uncertainty.

If the work is totally clear, the item is most likely quite small. When things interact, start to depend or become unclear - numbers will increase. A numerical estimate therefore indicates complexity and uncertainty, not work to do.

We purposefully de-scope capacity planning, because we understand that as soon as numbers increase, there will always be a rather high residual error. We value working software over guesswork numbers, so we only estimate enough to know what we intend to do - not what we will be doing for certain. 

We may have hindsight 20-20, but regarding the future, we will always be guessing.