Sounds familiar? I’m sure you have encountered something similar at the very beginning of your journey with Scrum. You were counting Story Points for a certain number of days to check how your team performed and answered some key questions:

1. Who performs best?
2. How many days are needed to deliver a task?
3. How many days are needed for the next release?

What is a Story Point (SP)?

Before I elaborate further the 2 Story Points ≠ 1 day concept (using a case study), I’d like you to get a better idea of what a Story Point is.

A Story Point is an arbitrary measure that expresses:

• the complexity of a task,
• effort needed,
• uncertainty, e.g. the technology is not known yet, the time spent on discussions may vary when you have to depend on other teams.

Please remember! A story point is a relative measure and not an absolute one (like measuring in days or hours).

Let me explain this using an example.

There are two developers – one senior and one junior. When they estimate a feature with SP, they should find the same task equally big (e.g 8 SP). It doesn’t matter if it’ll be delivered by the Junior or the Senior developer. 8 SP means 8 SP!

The time needed to deliver 8 SP is estimated by taking an average of the team’s past performance (not individual developer’s).

However, if they measured a task in days or hours, the senior developer would say 2 days and Junior would say 8 days. And both of them would be correct. So what can a product owner do with such estimation?

It’s useless because since Scrum teams are self-organizing, they do not know beforehand who will be responsible for the development.

If you want to check whether a task will be delivered on time, it is always better to ask the development team, than guessing it by converting story points to number of days (even though the development team’s velocity is quite constant).

For example 60 story points per 6 developers per 10 days. This does not mean that 1 developer will deliver 1 SP in 1 day. The entire development team is needed to deliver the user stories, especially when the tasks are interrelated.

By using Daily Scrum you can check how the team works and performs. You can also ask the team the right questions to get the information you actually need.

What a Story Point is not:

It’s not a measure equal to time, but can be used to estimate a release date,

It’s not a measure that describes the efficiency of developers,

It is not a measure to compare the performance of two different Scrum teams.

To provide estimates in Story Point development teams usually use two common methods:

• Planning Poker
• Swimlane Sizing

I will dedicate a separate blog post to explain in detail.

What does it mean to burn story points?

Every user’s story is estimated in story points which are burnt once it is done. By done I mean that it has passed all the necessary tests, the bugs are fixed (if there were any) and the user story meets the acceptance criteria described by the Product Owner and the Definition of Done.

To present the overall sprint progress towards the sprint goal you can use a burndown chart. Below you can find an example from a sample project.

There are 17.5 SP to burn in this sprint (left upper corner). As you can see, the team should follow the grey line that represents the sustainable development towards the sprint goal. The end of the red line represents the current status. On that basis, you can say that team should have burnt at least 5 SP.

It could indicate that the development team is lagging behind but in this case, they are not. Here the team have been working on the User Story that contains 8 SP, so it should be delivered at the end of the following day which means that they will still meet their guideline.

This type of a chart helps teams to check if they are going according to the plan. Checking this chart on a daily basis and asking the team if the sprint goal is safe or endangered is a good practice that prevents the team from failing.

It is the Product Owner who decides if user story is done. If not – Story points are not burnt and user story should be done again correctly. This is the case that indicates that user story description, acceptance criteria or/and the Definition of Done may require improvement.

If you are tempted to check this using Jira or other project management tools, it’s not a good idea as most probably you will receive an adverse effect. It doesn’t matter if you want to find “the best” developer or motivate the “weaker” one.

It’s ‘NOT OK’ to motivate and guess if someone is weaker by looking at their burnt story points as the person in question might be the best programmer in the team while burning the fewest points.

“Story Points are not used to measure developers’ individual performance.”

Moreover, please always remember that:

A Scrum Team is self-organizing and together performs sprint tasks to maximize the synergy effect. More experienced programmers help less experienced ones in their tasks and offer their knowledge while planning tasks. This takes a lot of time. As a result, the more experienced developers often leave the tasks incomplete while burning story points.

This also happens when a tester is a member of the development team and they are not assigned to any task. He won’t burn any points but this doesn’t mean that he’s inefficient as he still brings value to the team.

If you want to measure how a scrum team is performing, you should check:

• Whether it achieves a sprint goal or not
• If the team members constantly develop their skills
• Delivers high-quality results, and/or
• If its performance is predictable

To settle developers by who burns story points faster will lead to solely focusing on their individual work and will break the flow of information and knowledge between them. This is because communication takes a significant amount of time, which according to the developers could be used for pure coding.

Negative effects of solely focusing on burning story points and not working as a team.

The lack of communication leads to errors and misunderstandings. This negatively affects the quality of the final product as well as the speed of the entire team.

Another consequence of this action is that not everyone in the development team has the full knowledge of the product backlog. There could be times when, for example, someone is on vacation and no one else is able to complete the task.

The synergy effect of the development team is also reduced. The Product Owner and the team should work together on backlog grooming (refinement) and not just perform tasks “commissioned” by the Product Owner. The effect of synergy is a fundamental advantage of Scrum, so it’s not worth losing it.

Let’s recap

Story Point is a measure that works well in agile teams and changing environments. For teams which have a stable velocity, Story Points are better at answering questions about the planned release date than time estimates that often reflects customer expectations rather than the real time and effort required to complete the tasks.

For Story Points to answer questions on the release date, you must take care of the product backlog by regularly refining it. This shouldn’t take more than 10% of the Sprint time.

Everything in Scrum is strongly interrelated and interdependent. This framework is extremely coherent so giving up even one of Scrum practices can cause many unwanted problems in the project as a whole.

If you want to know more about Story Points, drop me a line. I’ll be happy to share my knowledge with you.