Should I be using story points at all?

When it comes to running a scrum process, the question of story points, and how it is to be used is often fiercely debated.

Here are some common questions on story point

1. Has your team adopted Story Point estimation? Why and why not?
2. Has it been useful? Is it valuable?
3. Do you use the velocity from the story point estimation for forecasting? E.g. with 21 SP each sprint, it will take 2 sprints to complete X stories.
4. How consistent are the story points across the stories? Are they wildly inaccurate? Or consistent?
5. How long do you take for estimation? What is your team size?
6. How long does it take your team to get the hang of estimation?
7. Do you equate 1 SP = 1 Man Day?
8. Who partakes in the estimation process? Story point poker?

There are many textbook answers that you can google online on how to run a scrum process, and how story points are to be used. Some are even questioning the need to use story points.

So what’s the truth here? Everyone has their own doctrine, and someone in your team would simply Google for an article and claim this to be the doctrine on how a scrum story-pointing process should take place.

Here’s what we at Xfers / FFG Engineering thinks about this:

1/ The output of estimation doesn’t matter. You are looking for consensus.

The activity of sprint planning is not so much to estimate how much work there is to do but to get to a consensus of what needs to be done for a certain task.

It's an activity where team members align on what a particular ticket means, what needs to be done for that ticket, and noting sidenotes into the ticket itself.

Through the act of aligning everyone’s thoughts you get 3 benefits:

• Elimination of assumptions and interpretation of particular tasks
• New joiners/people who are new to the team would gain context and possible solutions through the discussion process.
• Figuring out the complexity space / possible blindspots in approaching the task at hand.

2/ If consensus exists without the need for group estimation, then there’s no need to do estimations.

If a team doesnt have new members and is full of experienced individuals who know most of the codebase and architecture, they need not spend time on figuring out estimates, because most team members are more or less aligned on how long would a particular task take.

In this case, estimates are there primarily to determine velocity. Or if your tasks management board allows, velocity can be determined simply by the number of tasks completed instead of explicitly assigning a story point to each task.

However, another point to note here is that the maturity of the team has to be at a level high enough that supervision is no longer needed and can be trusted and proven to be trustworthy to deliver with consistent or increasing velocity. (aka velocity should be up only)

Without story points and estimation management, it’s going to be hard in identifying poor performers, since the team no longer keeps each other in sync and accountable. Something that can be mitigated by having a good monthly 1:1 process and peer review structure.

3/ If you want to go fast, go alone. If you want to go far, go together.

An individualist persona is one where I know I can deliver and I think it's a waste of time for me to create/move/update the tickets as I BLAZE through PRs. literally, I can create more PRs faster than people have time to review. why should I stop to make tickets?

Or why even bother creating tasks estimates or having meetings in the first place?

In a team, the point is not to have 1 person or a couple of people do alot of work, but to have the team be strong together. When these people go on leave or leave the company, we can be confident that the team is not strong because it has strong people but strong because people get strong when they are in the team.

Credits to HengHong Lee for crystalising the main points above.