_{By Stuart Corrigan, 2022.}

My friend Nigel likes to change his car more often than the average car buyer. He generally makes a change around seven to ten times per year. As he lives in Oxford and I live in Edinburgh, we rarely get the chance to see each other. We have a weird way to describe the timescale of when we’ll next meet: ‘I’ll see you in two cars’ time!’. Then, we do a time conversion in our heads and roughly conclude that we’ll meet up again between three and six-months’ time. It’s highly unreliable. Are we meeting in three months or six months? It’s a silly example, I know, but then so are the concepts of ‘story-points’ and ‘T-shirt sizing’ in Agile or project-based work (by the way, we’ve just conducted yet another Agile study 31 Epics, all shown on JIRA as matching the story point estimate – every single one took longer by around a factor of ten).

Story points were invented to roughly estimate the effort required to deliver a piece of work in a product backlog, however, there are several issues with story points.

1. They are based on effort as opposed to being based on elapsed time. We know, from years of experience and delivering hundreds of projects, that when planning, people build in safety. As a result, there is often a huge disparity between effort and elapsed time.
2. Some pieces of work do not conform to the elapsed time model. Work that requires a sign-off or has a dependency on another team has an element of effort and elapsed time.
3. As mentioned earlier, in most cases, the ways of working in a team leads to multitasking. This means that the work is naturally picked up and put down multiple times before it is completed. Thus, the notion of only capturing effort simply doesn’t work.
4. All the teams we have worked with tell us that they convert story points or T-shirt sizing back to actual time. In other words, they are using time anyway.
5. Many leaders tell us that their biggest frustration with story points is that they give a relative pace of the work being done, but that is meaningless. Is two thousand story points per week good or bad? Also, they don’t tell us when the work will be delivered. In fact, many report their frustration at the response to their question: ‘when will this be delivered?’ which is mostly, ‘this is Agile, we don’t work that way’.
6. We recently conducted some research on several teams within a large company. Each team was using a different number of points for the work (another issue – there is no consistency). We took each piece of work and put it through a control which would help us to understand the cycle time. The teams were pleased with themselves as they were completing a few hundred story points each month. However, we found out that each piece of work should have taken four to six days; they were small stories but due to the ways of working – despite differing in size and number of points – each piece of work took between forty-five and sixty days. Nobody knew, and it certainly wasn’t a great rate of Throughput given the size of the work.
7. Ron Jeffries (the inventor of story points) wrote that he is sorry he invented them. They were, he says, designed to capture the difference between the effort that goes into a piece of work and adding a load for interruptions. He says that using them to predict when something will be finished is ‘at best a weak idea’, and that ‘comparing teams on velocity is harmful’.

Story points don’t work. Especially, if you want to know when something will be delivered. So, what would we recommend you do differently?

1. We have already recommended collaborative planning. This means that those people who know most about the work should be in the room when the planning is being done.
2. Don’t plan too far in advance. If you try to plan and estimate a project that lasts longer than 6 months and you are hoping to land it on the given due date, you are heading into problems – it is too big to estimate.
3. In the same vein, do not set dates for milestones, or accept that they are estimates. When you set a target (as mentioned in my previous blog entry) you often invoke a dysfunctional behaviour in the team – student syndrome. Parkinson’s Law dictates work expands to fill the time available; if I have two weeks, I will take it. What manifests will be, at best, an on-time delivery but if we accept unclean work, a poor approach to unblocking and multitasking as the norm, then the project will be late… guaranteed.
4. When planning, try to estimate in smaller chunks, we recommend big chunks (‘epics’ within Agile) to be around fifteen to twenty days (approximately a maximum of one month), and small tasks (i.e., ‘stories’) to be a minimum of one day, and a maximum of five.
5. Additionally, when planning, use two estimates. ‘Focused’ and ‘safe estimate’ and call the difference ‘buffer’ which you will take out of the task and put at the back of the project. This can be used to determine whether you are running late. For more information on the this, you can email me on [email protected]. We can arrange twenty minutes on a teams call to walk through the concept.
6. Use actual time, not points or T-shirt sizing.

In summary, and especially if you want to know when a project will be completed, cease the use of story points or T-shirt sizing and move toward time-based work. Unless, of course, you are meeting Nigel, then you can arrange a beer in two cars’ time if you don’t care if he actually turns up – then it might work out just fine!

If you would like support with a late running project, you can arrange a free phone call with Stuart himself, or one of our other Critical Chain Project Management experts. On the call you can describe your environment, the challenges you are facing and the goal you want to achieve. Our expert will then offer you the best way forward – whether that’s free resources to learn more or a jump straight to a rapid implementation (best if you are working to a tight deadline).

Arrange your free conversation with one of Goldratt UK’s experts by emailing [email protected] or phoning 01234 834510.