Is your project team on the same page regarding Story Points?

The content hereby assumes that you solely use Story Points and velocity-driven planning in your project.

There are various definitions of Story Points. Essentially, these definitions appear to be similar and relatively straightforward. Here are two of them.

1. “Story points represent a unit of measure devised to gauge the effort required to execute a user story in Agile project management.” – agile-academy.com
2. “A Story Point is a theoretical measure that expresses the difficulty level of any piece of work” – NashTech Scrum Process

Due to the seemingly straightforward definitions above, we may have focused mostly on the techniques of the story pointing without realizing that there is an ambiguity (or perhaps we implicitly understood and assumed ourselves) regarding the scope of applying Story Points to different types of work within a project.

There are two main purposes of using Story Points

1. For Estimation and Planning – the Story Point serves as a unit to measure the amount of work, features, or products, and thereby to answer the question “how many Product Backlog items can be completed by the Scrum Team within one Sprint” in a sprint planning.
2. For determining Team Velocity and Product Roadmap – by careful tracking the delivered Story Points in each sprint, we obtain the average amount of Product Backlog items transformed into an Increment of the product during a Sprint and thereby to help PO to be able to answer the question “when will we get there” when constructing the product roadmap.

So, is there any problem when using Story Points?

The first problem is the inconsistency in the application of Story Points deriving from the confusion in their definition as mentioned above. For example, sometimes a task or a bug is not assigned points, while other times they are. This inconsistency leads to inaccurate measurement results such as sprint backlog estimates or velocity because they are not using the same reference scale. Consequently, planning or constructing a roadmap can be flawed as a result.

The second problem arises from the conflicting interpretations of Story Points among stakeholders with different viewpoints. For example:

• The PO may question why a sprint, which is preparing the framework for a new product, is reported with 100 delivered points because he doesn’t see any usable outcome from the sprint. However, if the reported delivered points are 0, there will be other stakeholders’ questions because they believe, based on the second definition mentioned above, that every sprint should always have a certain number of delivered points.

• The PO and BA often tend to interpret the velocity report as only considering points from User Stories so that they can easily determine the roadmap when they have estimate for the product. However, relying solely on User Story for velocity calculation makes the velocity unstable across different sprints, and you may have to address the concerns of many other stakeholders due to this instability.

I think ‘yes’. I believe that there is implicit understanding about some unofficial points when it comes to planning. Let’s review the two scenarios below:

• If your project/team only assigns points to User Stories, how do you plan for other item types such as Tasks and Bugs that do not have points assigned to them? It’s certain that you must have to assign unofficial points, which are referred to as “work capacity” points in this blog, to other work item types.
• If your project/team assigns points to all item types, are you sure you don’t use any additional points? There are many cases where a work item is only partially completed and needs to be carried over to the next sprint. In this situation, counting the total points of that work item for the next planning session would be incorrect since only half of the work remains. However, reducing the points on that item is not advisable (although splitting and delivering half can be a great solution, assuming it’s not applicable in this case). In this scenario, you need to assign different points to represent the remaining work on that item for planning purposes. In this blog, they’re referred to as “remaining” points.

Due to the implicit understandings regarding unofficial points as above, you will encounter difficulties with questions such as ‘Why are you planning 70 or 120 points for a sprint when the team’s velocity is 100 points?’.

If you are unsure whether your team is on the same page regarding Story Points, the section below might help you.

Imagine asking the following questions individually to each team member to see if your project team is on the same page.

1. Do we assign Story Points to technical tasks?
2. Do we assign Story Points to defects and technical debts?
3. Do we assign Story Points to other tasks like study, research or setting up local environment?
4. Are Delivered Story Points (velocity) calculated only for User Stories or for all types of work in our project?
5. Do we solely use Story Points, or do we also use any other unofficial points in the project? What are they and what are they used for?

The Scrum Master (SM) is not the most authoritative voice nor the sole decision-maker for a Scrum team. This is particularly true when the SM joins a pre-existing project with its own established culture. However, as an SM, you cannot dismiss the questions or complaints mentioned above due to inconsistent understandings about Story Points within your project.

What a SM can certainly do is to clarify the inconsistent understandings present in the project/team and facilitate the creation of a consensus among stakeholders regarding the pros and cons of that choice.

In my opinion, if your project relies on Story Points for estimation, planning, tracking velocity, and constructing a product roadmap, and is facing the issues mentioned above, having a project wiki page that describes the definition and usage of Story Points, along with comprehensive explanations for planning, tracking velocity, etc., would be beneficial for your team and your project. It is also important to ensure transparency in the project wiki page regarding any additional unofficial points like “work capacity” points and “remaining” points used for planning purposes.

Some open questions for you

• Do you think that asking the 5 questions above individually to your project team members and your client will have the same answers?
• Do you think it would be beneficial to have a project wiki page describing the definition and how to use story points in your project to avoid any misunderstandings or inconsistencies within the project/team?

• Do you have any other best practices that effectively address the issues mentioned in this blog?