5 Common Misuses of Points by Agile Teams

If you have ever had the chance to watch the tv show “Whose Line is it Anyway?” you probably remember things like “Scenes from a hat” or “Greatest hits”, but also that points were useless. The host, Drew, would assign 1000 points to something without any specific set of rules. At the end of the day, points were meaningless for a reason, everybody achieved their goal, made the audience laugh and had a great time.

The idea of points in Agile is similar; we don’t care about the points! We just want to deliver. In order to deliver, points allow teams to assign an estimation of complexity to a specific user story. The sum of points at the end of the sprint becomes the velocity, which helps stakeholders forecast how many sprints a specific release or project may take (again, just an estimate). Points used for good can help a team a lot, but if they fall into the wrong hands there could be serious damage to the team’s image, dynamics and create some angry stakeholders. Here are 5 common misuses of points that I’ve seen through my many years of being a Scrum Master.

Compare Teams

When understanding agile, it’s helpful to think of a metaphor: If we think of every person on the team as a world or planet, the entire team together make up a galaxy. Every world in a galaxy and every galaxy in the universe operate differently. People, just like worlds, and teams, just like galaxies, have their own way of operating and estimation is just one of them. Just like comparing planets doesn’t make sense, running reports to compare teams on their points doesn’t make sense either. For example, one team can be using Fibonacci (1,2,3,5,8,13…) and another one powers of 2 (1,2,4,8…), so their velocity would be completely different. Even when you have a standard for all teams using Fibonacci, what an 8 means for one team, may not be the same for another.

Use Points as a Measure of Time

This is one of the areas I struggle with the most. Once I heard someone say: “There’s a holiday coming, let’s adjust the points”. Adjusting the points is as subjective as you can get. It’s far easier to adjust hours, which are more real. Suppose each one of the team members has a 6 hour capacity per day (I mean they have to eat and go to the bathroom!). If there’s a holiday coming and you have a team of 4, you know you’ll have 24 hours less time for the sprint. This will be shown in the burndown chart and reflected on the board. To achieve this, I suggest capacity-driven sprint planning (which I will be talking about in a future post).

Estimating effort

The word effort can lead to thinking about points in terms of time. That’s why I like to use the word ‘complexity’ for assigning points to a story. Every user story has a different complexity and this is directly correlated to the team; how experienced they are in a specific technology, their infrastructure, etc. Every time you ask for an estimate to analyze how complex it is for your team, remember estimating complexity has one purpose: serve the team, help them become more cohesive and know each other better.

Why do I keep coming back to the team? Because every user story should be able to be owned by one or many team members. The complexity has to take into consideration the experience of a team as a whole and not only an individual. If whenever a complex user story appears, your tech lead estimates it and works by himself on it, that’s not a good sign!

Remember, a user story is not complex because it’s time-consuming. The product owner can ask a team member to manually fill out an excel sheet with user’s data; 4 columns and 65000 rows one by one. This could take hours, but complexity wise this story could be a 1 point story. In short, for time-consuming user stories, tasks and hours are your friends. For complexity, use points.

EPIC-phobia

Sometimes when estimating points, the team wants to avoid splitting stories (they’re tired or just being lazy). But, at the same time, they want to make sure they show that a story is ‘big’ enough. The common answer to this is to use the number closest to an epic. On my team, we consider an epic to be a 21 point user story. In that case, we need to talk about it and try to split it. So, when I see a lot of 13’s on the board, I ask the team if we can split those into smaller stories. Sometimes the answer is just no, but other times we find ways to provide further value in splitting stories up into two or more separate stories.

Measure productivity

In Agile, you want to focus on delivery and to provide small chunks of business value to customers sprint by sprint. That’s why you cannot measure productivity throwing around reports with velocity graphs, it needs to be more real! In terms of productivity, any measure should be handled inside the team, with the sole purpose of improving and telling the story after the sprint. Completion against Commitment is one good metric in which points can help provide a snapshot of the sprint. To read more about Completion against Commitment (CaC), please see my previous blog post here.

I hope this article helped you and your team understand how to use points in agile the right way. In general, points are means to a greater end; to tell a story about the team, the sprint and the project and, finally, help your team succeed. Subscribe to our blog and stay tuned for my future blog posts to read more about best practices and the agile process.

—

Gorilla Logic only hires the best software engineers. Think you have what it takes to be a gorilla? Check out our careers section below.