The Trouble With Planning Poker

12 March 2019

Photo: Unsplash

I am struggling to see the value of Planning Poker. There, I have said it publicly although I have struggled with the concept for some time.

My history with the technique started at a previous company. But we only tried it briefly before I left. That alone didn’t really help me see the value. One of my team suggested using it about a year ago, as the team grew. I was happy to trial it an see where we got with it. One year on and I am looking for a replacement for it.

The idea is a sensible one and if you have never used it then you can read about it in full here. In short:

• Your team identifies a number of user stories to “point”.
• You review a story and discuss it to the point that as a team you all agree with what is involved to complete it.
• You then vote on the effort using planning poker cards. The cards have values that start at 0.5 and slide up the Fibonacci scale.
• You discuss the points people have voted with and if anyone disagrees they are asked to clarify. You then go back to step 1 and repeat until you reach consensus.

There are many benefits including team collaboration. The idea is that you develop over time a team “velocity”. This is the average number of story points that you complete per sprint. Then the number of story points grouped into any planned sprint should not exceed what the team can deliver. This should allow you to plan when work is done. It all seems logical, doesn’t it?

The main problems I have discovered relate to effort and knowledge:

• Effort - is relative to a given developer. It’s based on some variable factors. Most of the factors come down to experience. Development experience, language and stack experience and experience with your application’s code. My current team ranges from a first time developer to seniors with 10 years plus experience. That is a wide range of experience for the amount of effort to be relative to. The difference required in effort grows in line with the complexity of the story as well. Correcting a typo is the same effort regardless of experience. But we define a story that requires a whole change to a calculation engine. That will take the experienced developer less effort than the junior.

• Knowledge - again development knowledge and experience as a developer all come into play here. A new developer will have less knowledge when they start on the team. That is obvious. It can be beneficial in other ways such as when they propose alternative approaches. But as they have grown their knowledge of your code base the effort they spend completing work reduces. This is the same for more experienced developers. They know patterns and approaches to solve problems. So the effort is reduced.

This is all highlighted in Planning Poker. It becomes clear that as you discuss a story there will be more dominant voices in the discussion. They are usually experienced developers who know the code. They never ask the interesting and usually thought-provoking questions. They come from the more junior developers who are trying to find out more about the story and any related code. So you end up not discussing the merits of the story. You end up with some of the team agreeing with what needs to be done. You then all vote and the difference between the team is clear. The more knowledgable team members ask those who voted different why. There is a discussion and while you try and drive the process fairly what tends to happen is the less knowledgeable developer’s fold. They agree with those “that know” and you get to an average pointing and move on. The process is not for less confident developers of that I am certain.

Now I put on my business hat. The process so far is about pointing stories with effort and building a velocity. The theory is that the velocity, combined with prioritisation and sprint planning, will provide an estimated delivery date. It never ever does. The reason is back to the relative effort it takes a developer to complete a task. I have run reports on this to discuss with the team. The developer who suggested the process wrote a supporting document to educate the team on points vs effort. In the document, a typo, for example, is 0.5. A change to a feature with some logic and a new DB column might be a 3 or a 5. When I report on delivered work and compare story points, the same points for the same task for different developers can vary by an hour or much more. The reports show that actually even after a year on a code base we are all familiar with, we can not point correctly.

Before you shout, I know that points are not time-related. But actually, they are. What use is a system of estimation to a business that will deliver in different periods of time based on who is doing it? Yes, I remember the agile manifesto and focusing on changes rather than plans. Businesses need to know when to expect a change. In my experience, you are better to give a far-out deliver date than be in the position of having to give a ballpark based on who is delivering the work. If they know it is coming then most times the business can adapt its plans.

The only thing the story points are useful for is guidance but not estimation. It can be useful to track developer and team effectiveness. The process hasn’t solved the development estimation problem. It is a problem that the entire industry suffers with and my theory around that lies with it being a creative task. No one asks a painter or a sculptor when their work will be ready? That’s not entirely a fair point but my thoughts around creativeness of development are for another blog post.

Right now with a big looming project to deliver, I am looking at alternatives to Planning Poker. I have briefly looked at Magic Estimation (it’s not) but have found nothing groundbreaking.

If you or your team have replaced Planning Poker I would love to hear more about what you have selected, why and how its working for you. If you have any thoughts around Planning Poker or think I am wrong about it (I am totally open to being wrong) then contact me via twitter or email.