The Myths About Story Points

There are many misconceptions about time and estimating in Agile teams. One I hear all the time is that story points are no use as an estimation metric unless they are standardised across the organisation. Another is that story points must ultimately equate to time. Another is that story points are the only valid way of estimation. Another is that estimation is always necessary.

Story points are an abstract sizing metric, and are not intended to represent actual time. The problem with abstract sizing is that unless you have a standard applied across the organisation then nobody outside the Agile team can understand their meaning. The problem with standardisation is that it is usually only achievable by equating it with delivery time. The problem with equating story points with delivery time is that it is utterly bananas. The purpose story points serve is to allow for teams to understand the relative sizing of the stories in their backlog. This can allow them to prioritise work and plan accordingly. It can also be used as the basis of velocity calculation, where the number of story points delivered in a sprint will fluctuate over time as the nature of the team changes. I have italicised ‘can’ in the previous sentence because there is a common misconception that story points are required to measure velocity, but velocity can also be calculated by simply counting the number of stories delivered in a sprint. Obviously this approach doesn’t account for the complexity of what was delivered, but a) it usually averages out over time, and b) story points aren’t great at that either. There have been a very high number of retrospectives I’ve witnessed where the reason given for sprint failure was that the estimates were wrong. Complexity often emerges as the sprint evolves, it’s part of being agile! Revising the estimate to reflect the actual complexity of the story after it’s done just so that the velocity accurately reflects what was delivered is an anti-pattern I’ve witnessed on many occasions. The clue is in the word ‘estimate’!

The other thing to be aware of is that some things don’t bear estimation. You may want to time box certain R&D activities, but you can’t usually estimate them. Similarly, analysis work is usually unquantifiable: Rabbit holes often go quite a long way, but until you’ve explored them you don’t know that you know everything you need to know.

By all means estimate work, but don’t let estimates cripple your teams and/or your organisation.

Change for Change’s Sake

Most people equate Agile with change. The ability to adapt work practices is definitely a fundamental part of Agile. When there are hard times in a project (and there always will be), it is very tough to think objectively about the root causes. It is even harder to stay the course when things are going wrong and change is an option. However, sometimes staying the course the right thing to do.

Retrospectives are designed to be a safe space for reflection on the team’s processes and ways of working. It is often misinterpreted as a time where it is necessary to change these processes and ways of working. If you talk about anything long enough you will find things that need to change about it, and if you are in a stressful project it is doubly easy to do so. Change is good, said somebody sometime somewhere, and it is oft repeated and is often correct. It doesn’t mean that it is necessarily good. I remember reading somewhere that there are times in our lives when we are more receptive to change, and changing things outside these times can lead to unnecessary stress. I’m not sure I believe this completely, but there is certainly such a thing as unnecessary change. The rhythmic nature of sprints – and by proxy retrospectives – means that Agile teams often feel pressured to identify things that need to be changed. Sometimes they do need to be changed, but:

  • Is it the right time to change it?
  • Have you waited to see if it actually might be something else that needs to change?

Change is disruptive, even if it’s necessary, and the instinct to change something just because it feels wrong at the time overlooks the possibility that it is circumstantial.

Unnecessary Hierarchy

Another common problem that I’ve experienced first-hand is the emergence – either by nature or by nurture – of hierarchies within Agile squads. Regardless of whether you are using Scrum or Kanban, there are effectively no strictly ordained roles and there should definitely be no hierarchy.

Given the absolute nature of the above statement, it is surprising to note how rarely it is enforced. The number of times I’ve had my job title prefixed with the word “Lead” as part of a Scrum team is shocking. “Lead BA”; “Lead Developer”; “Lead Tester”. None of these make sense, and are counterproductive when it comes to empowering the team. The problem is that it is a very easy habit to fall into because it is usually easily justified: “We need leads to act as team representatives to the company as a whole”; “We need leads to coordinate standards within the team”; “We need leads to help filter out the noise and interruptions for the rest of the team”. All of these sound like very reasonable statements, which will always carry a lot of water for those outside the team who will, for example, usually prefer to deal with the same individual. It may also make sense to the team to have these representatives and allow everyone else to just get their heads down and work. Because of this, most teams turn a blind eye to the detrimental effect that this unnecessary hierarchy has on the team’s cohesion. As long as there is a “lead” developer, the other developers will never be as empowered. The same goes for “lead” tester and “lead” BA.

This is one of the most insidious anti-patterns that exists in the world of Agile: It feels natural. It feels comfortable. It is thoroughly destructive to the team.

Can’t Build Me an Aeroplane

Away from the personal side, the other problem that usually gives Agile a bad reputation is an organisation’s determination to apply it in a blanket fashion. There are things in life that cannot be solved by Agile.

Aside from personal empowerment, one of the big selling points of Agile is that it gets stuff to market sooner. Thus allowing for the feedback loop to be shortened and ultimately for more relevant and focused end-products to be created. This is clearly not going to work for everything. Obviously, if my company were to build an aeroplane with this mindset there are going to be a number of problems in my company’s – and that of our poor customers – fairly immediate future. Some things in life need a watertight set of requirements before any development should begin.

“So: wings… Sprint 2?”

The example of an aeroplane is clearly absurd, but you would be shocked to hear of some actual examples of products that have been developed using Agile Methodologies.

As with previous posts, it is important to apply critical thought when determining whether Agile will actually solve the challenges that you are facing.

Trust, Motivation & Candour

If applied incorrectly, in many cases Agile will actually have the opposite to the desired effect. The biggest reason behind this is trust. A team can be broken for, ostensibly, many reasons. However, most branches of team dysfunction have effectively the same root cause or effect,which is a lack of trust. Like all things in human relationships, cause and effect has a circular nature: Lack of trust leads to bad relationships; bad relationships lead to poor performance; poor performance leads to a lack of trust.

One of the fundamental points of Agile is empowerment: You are giving each member of each team the ability to self-manage. They are all responsible for both themselves and the higher functioning of the team as a whole. If team members do not trust the other team members then this empowerment can be catastrophic. For this reason, wherever I am involved in the implementation of Agile Methodologies within organisations, I usually insist on sessions for each team to help them build on cognition/mindfulness. Team solidarity has an incredibly important part to play in the creation of an empowered team. The team must be aware of each other’s skills, but a far more important part of an Agile team cohesion is understand each other’s motivation. All Agile coaches will tell you that candour is one of the pillars of Agile, and they are right. The ability to communicate is critical, and the empowerment to raise issues with one another in a safe environment is a big part of that. However, without understanding that everybody’s approach and reaction to the working environment is different, candour usually creates nothing but conflict.Conflict reduces trust; reduced trust reduces destroys the safe environment; and where there is no safe environment there can be no candour. The circle continues.

Silver Bullet

On many occasions I’ve heard company executives talk of Agile in terms of it being a scourge on modern businesses. This is usually because they have bad experiences of its implementation within their organisations. Sadly, bad implementations of Agile are rife, and there are usually two main reasons for this:

  1. The people doing the implementation do not know enough about the nuance of Agile Methodologies to be able to champion them and direct others.
  2. Agile is being brought in for the wrong reasons.

The most important thing to remember is that it is not a silver bullet: It will not solve all types of issues. For example, if the primary reason behind your company’s introduction of Agile Methodologies is to address a lack of cohesion within your teams, then you and the teams you are seeking to help may be in for a nasty shock. If you have an engine that’s not running smoothly and decide to fix the problem by spraying engine oil at the engine from a hosepipe, you are probably not going to fix the engine and you are likely to introduce a few new problems. Like engine oil, Agile is something that can improve performance, but you need to know how to use it.

Agile does not automatically:

  • Make teams productive.
  • Make people work more effectively with each other.
  • Create a skilled team.