In Agile Methodology, points and velocity have been seen as crucial elements for the success of many teams and projects. A few years back one of my teams was working on a new mobile application for a popular restaurant chain. The project was a complex one, as it required integration with the restaurant’s existing systems, as well as the ability to place orders and make payments through the app. As the team began to work on the project, they quickly realized that estimating the complexity and effort required to complete the various tasks and stories was becoming increasingly difficult. The team was struggling to come up with accurate estimates, and as a result, they were falling behind schedule.

In an effort to get back on track, I decided to understand along with the project manager assigned to the team on how exactly they are estimating stories. And to my surprise I learned that the version of points and velocity understanding is way to confusing for them. We began by assigning points to each task and story based on their relative complexity and effort required, then used velocity to estimate the number of points the team believed they could handle in a given sprint. Trust me, it might sound simple but it was nothing near to simple. In this article I will try to break some of the learnings that helped my team to understand things well.

Basically, in Agile development, teams use the terms “points” and “velocity” to estimate the complexity and effort required to complete a task or story. However, these terms can be confusing as they are not meant to measure the business value of the work or evaluate how hard the team is working. So, points are intended as a relative metric to help developers predict the effort required for different tasks. And, Velocity is used to estimate the number of points a team believes it can handle in a given sprint. One of the main sources of confusion is when team members start to think of points and velocity as a way to measure the value of the work or how hard the team is working. This can lead to issues such as gamifying points and inaccurate estimation. Additionally, equating points with time spent working or comparing the point velocity of one team to another can also be misleading.

First: breaking the confusing terms in Agile methodology

Lets look at some of the basic terms that you should differentiate between in order to have an understanding of the points and velocity system.

What’s the confusion with the points and velocity system?

Points and velocity can be confusing for many people as they are abstract concepts that don’t directly correspond to real-world units of measure, like hours or days. The process of estimating points can be subjective as well because with different team members may have different opinions on the size or complexity of a task. This leads to discrepancies in point estimates and makes it difficult to compare to the relative size of different tasks.

Also, these terms confuse few people because they are often used in conjunction with other Agile concepts, like sprints and backlogs, which can be complex and difficult to understand on their own. Additionally, the use of velocity as an estimation tool, it’s based on the assumption that the work of the team will be consistent over time, which is not always the case.

Ironically, points and velocity are actually not the only ways to estimate complexity and effort in Agile methodology, and different teams may use different methods for the same activity which further add to the confusion when different teams are using different estimation techniques and terminology.

Due to the confusion caused by these terms, some agile circles have called for eliminating points altogether, arguing that they are not only confusing for the team but also a distraction from the real work. The idea behind this approach is to avoid the competitive associations people tend to make with points and velocity. However, it is important to remember that points and estimation are crucial tools for teams to better understand and predict the effort required for different tasks.

The big question: How points & velocity can help in estimating complexity & effort

Let’s say a team is working on a project to develop a new mobile app. The project is broken down into several user stories, such as “As a user, I want to be able to create an account” and “As a user, I want to be able to view my profile.” Each of these user stories is assigned a number of points, based on the relative complexity and effort required to complete them. For example, the “create an account” story might be assigned 8 points, while the “view profile” story might be assigned 5 points.

The team works in sprints, with each sprint lasting two weeks. At the end of each sprint, the team assesses the number of points they were able to complete, and this is their velocity. For example, in the first sprint, the team completes a total of 15 points. In the second sprint, they complete 12 points. And so on.

Using this information, the team can estimate how many points they will be able to complete in future sprints, and use this to predict when the project will be completed. For example, if the team’s velocity is 15 points per sprint, they can estimate that they will be able to complete a total of 60 points in four sprints. If the total number of points for the project is 100, this means the project is expected to be completed in 6 sprints.

Also, its very important to understand that in Agile development, it’s a team effort and the team members collectively assigns points to the user story, it’s not an individual effort. There are several techniques that teams uses to assign points to user stories including the most common one i.e. “planning poker“.

Planning Poker is a consensus-based technique used to estimate the relative size of user stories. It’s a process where team members discuss the story and each member independently assigns a point value to the story. Once everyone has assigned a point, they reveal their points and discuss any differences. The team then continue this process till they reach a consensus on the point value of a story.

The point value assigned to a story is based on the complexity and effort required to complete it, but it’s also influenced by other factors such as risk, uncertainty, and dependencies. The team members might use Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34) or powers of 2 (2, 4, 8, 16, 32) to assign point value.

But, this process of story pointing is not an exact science and it’s not always possible to predict the exact effort required to complete a story with 100% accuracy. It’s an estimation and the team should be prepared to adjust the point value of a story as the project progresses and new information becomes available.

The above example that we had discussed is a simple one and in real-life scenario, there are many other factors that can affect a team’s velocity, such as changes in team composition, delays, and unexpected complications. Therefore, this method should be used as a general guide rather than an exact prediction.

Closing Note

In spite of the fact that Agile can work without points or estimation, it’s important to remember that this approach may not work as well for teams with less experience or self-awareness. Communication, understanding, and alignment among team members are key to successful Agile development and using the principles and values of Agile and Scrum, teams can effectively work together and achieve their goals. The point system and velocity, although not directly related to value, are still useful measures of the team’s progress because they help predict the effort they will have to put in. We need to use them as an aid to the team, not as an end in themselves. This way, teams can better understand and predict the effort required for different tasks and use that information to make informed decisions about what to work on and when.