Eight Points for One Team Is Two Points for Another Team
Is agile a giant meme?
I’m strongly leaning towards yes. Modern “agile” has seemingly almost nothing in common with the original Manifesto for Agile Software Development which is worthy of a separate article.
In my ongoing quest to explore the problems that are endemic to modern software development, I decided to focus in particular on estimation and the disaster that is “story pointing” (estimation).
“The main problem with estimates is that estimates are always based on guess work. You’re always guessing. You can make a claim that estimates are based on observing past behaviour, but the fact is that what you’re implementing is something that hasn’t been implemented before.”
— Allen Holub
What’s in a story point anyway?
Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work. Teams assign story points relative to work complexity, the amount of work, and risk or uncertainty.
— Atlassian, who we have to thank for Jira’s existence.
The idea behind story points
A scale is used where the lower bound is considered the “easy” work while the upper bound is considered the “hard” work. What “easy” and “hard” work means is subjective and depends on the team. For example, I consider work that is vague or needs further research to be an “unknown” and therefore “hard” and thus assigned a higher value. Already, perhaps a problem becomes evident - estimations are guesses.
That’s about it. There is no formal way of calculating story points.
Misuse of story points
In my experience I’ve found that certain agile proponents have an ever-present dogmatic and overbearing view of all things agile - to the point of resisting change. This is ironic, as agile is supposed to be about adapting to change. It’s anti-agile.
How many of these anti-patterns sounds familiar?
Failing to realise story points are an estimate. Despite the phrase “story point estimate” there are often cases where stakeholders seem totally oblivious to the “estimate” part. In other cases, the assigned story point value is often taken to be the exact amount of effort required to implement the backlog item.
Pressuring or coercing developers into choosing a lower number. Pressure being applied to developers in order to make them feel like they have no choice except to “estimate” a lower amount of effort in order to be left alone and avoid the stress of being singled out. Even worse, then blaming the developer at the end of the sprint when work “takes longer” than estimated.
Immediately discounting high or low numbers. Similar to the previous point. Immediately disregarding any estimates that are an outlier compared to other team members. A score wildly different to the average usually means one of two things - that either they didn’t understand the scope of the work or that they have unique insights and concerns about the task. Some stakeholders ignore those insights and concerns because they are inconvenient.
Comparing and judging developers workloads based on the total points. This is a terrible practice that only leads to resentment and unfair representations of workloads. Sometimes a developer completing many tasks with smaller estimates are perceived as doing more work than a developer completing tasks with higher estimates that take longer to implement. Both developers are contributing yet one gets little to no acknowledgment.
Treating story point estimations as hard immutable facts. Once an agreement has been made over how many points a story is to have, there is no way to update the value of it as more discoveries are made without unnecessary drama and arguments. Of course, this should not be the case as changing is supposed to be part of the manifesto. It inevitably leads to everyone estimating higher values in order to get breathing room.
“Responding to change over following a plan”
Berating developers when they realise a story was over or under estimated. Similar to the previous point. Discouraging and discrediting developers for their estimates, often on a regular basis. This needs to stop.
30+ minute debates to decide if a story should be 1 or 2 points. Long and protracted discussions are sometimes needed, that’s just life and the nature of development. Perhaps the bigger picture system architecture needs to be considered or maybe there is a concern an approach could lead to technical debt and highly coupled code. On the other hand, some of the debates around whether an “easy” task should be assigned 1 or 2 points etc. are captious and a waste of time and patience.
Expecting the same “velocity” every sprint. This one is more subtle and seems to sneak in unnoticed - at least until after a few sprints have been completed. It might be subtle, but it’s a debilitating practice that only serves to exhaust teams and it’s members over time. This can manifest in multiple ways often concurrently. Making a specific number of story points per sprint a mandatory target. Adjusting story points to “fit” that target. Bringing in extra items from the backlog to “fit” the target thus increasing work load on the developers.
Deliberately estimating inaccurate story points that will help create a “perfect” burn down chart. Similar to the previous point but needs to be pointed out specifically. There’s a couple of angles at work here: 1) the developer that just wants to work and is fed up of being berated so “estimates” a story point that will keep the scrum master happy. 2) the scrum master being asked why their team does not have a perfect burn down chart and so massages the story points into something that the executives want to hear and see. Even if the burn down chart is totally inaccurate as long as it’s a perfectly linear line that’s all that seems to matter for organisations “doing agile”.
Comparing one team with another team in terms of “velocity”. Every team has a different understanding of what a story point is “worth”. This makes story points and in turn velocity ultimately meaningless metrics that simply cannot be used to compare the output of two or more teams. Any decisions based upon this are going to be flawed. This leads to scrum masters and product owners having to present reports to executives that indicate one team is “performing” better than another. Obviously, that is a flawed comparison and despite an organisation “doing agile” they seem to never take these nuances into account and instead pressure teams.
What can be done about it?
At the risk of sounding tautological, a solution to all of these problems is to actually be agile. Because all of those listed problems are an indicator that a team or an organisation is not actually agile and is only “doing agile” in name only.
All of those problems are anti-agile. Pretending to estimate work every sprint is a complete waste of time - time that could be spent, you know, designing the product. In short, improve your processes.
Either estimate fully, taking all the nuances and caveats listed into account, or, don’t estimate at all and focus on the customer needs and creating useful software.
No estimation at all?
There’s a growing movement towards not estimating and instead focussing on delivering early. It’s interesting how this is a relatively recent phenomenon considering a key point is the following quote. It’s almost like we need to remind organisations about the core ideas behind agile.
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
“Building the wrong thing on time and within budget doesn’t buy you much.”
“So they look at something like Agile and they try interpret it in a way that works according to their world view.”
Where did it all start going wrong?
I believe it started going downhill not too long after it’s conception. Perhaps that is a little harsh but I found the following quote from Robert C. Martin’s talk particularly insightful. For context, this is a discussion between two of the original authors of the agile idea not long after it started gaining traction.
Ken came to me some time later, he said, “Bob I’ve got this idea. I’m going to run a class which I call Certified Scrum Master Class”. I said, “What?“.
“Yeah certified scrum”, I thought this was the dumbest Idea I’d ever head. He said “I’d like to use one of your classrooms”.
He started getting people to come to these courses, he started charging for the courses, more and more people came, the more he charged the more people came. He started giving out these certifications “Hey this is kind of cool this certified scum[sic] thing”. Started building a little organisation off to the side - the scrum alliance popped up out of that. Lots of money going in that direction, lots of money going in the agile direction.
Who do you think was taking these courses? These “certified scrum master” courses? Was it developers? No! See I was a developer and I thought it was stupid and all the other developers I talked to said “This is stupid!“. Who was it that didn’t think it was stupid? Project managers. “Oh not thats not stupid at all we’ve done that for years” … so these project managers started to line up for the certified master class.
The two main points here are that not only did developers not take these courses but that it was mainly non-technical people taking them: ”Who was it that didn’t think it was stupid? Project managers.”.
As I previously mentioned I wrote this article primarily for two reasons. Firstly, I’m not too happy with the general state of the software development industry. Secondly, I wanted to write down what I consider to be failings in the “modern” take on agile (that is, it’s not even agile as described in the manifesto) and in particular the obsession with estimations that rarely work out in the real world. I believe that #NoEstimate is a path forward especially after watching Allen Holub’s talk. He eloquently describes the same thoughts that have been formulating in the back of my mind.