Points of Confusion in Agile

Share this article

One of the most confusing things about agile may be the fact that we call the estimated units of complexity and effort that will go into completing a story, points. We also use the term velocity to help estimate the number of story points a team believes it can handle in a given sprint. As soon as you introduce terms like these, engineers and managers alike instinctively start to think of them as a way of measuring the value of what is being done.

In fact, points and velocity have absolutely nothing to do with measuring the business value of the work done by the team. They also have no use as a tool for evaluating how hard the team is working, or how much objective work they are getting done. The true value of points is that they represent an abstract and relative metric for estimating what it will take to get one story done compared to another. Ultimately they are intended to help the engineers on the team get better at predicting what will be involved in addressing new stories. But trying to convince managers and engineers of this can be confusing when they see shiny points and graphs that look like they should be going up and to the right.

Where the Confusion Starts

There are some tendencies to watch out for if you think your team may be misunderstanding and misapplying the concept of point estimation in your agile process:

  • Thinking that the more points the team completes, the better the team is doing. This can lead to gamification of points and inaccurate estimation.
  • Equating points with time spent doing work. This can undermine the ability of a team to track their actual velocity toward completing shippable product features.
  • Conflating the forward-looking nature of point estimation with the more objective need for time tracking and optimization. This can quickly undermine the power of relative estimation.
  • Comparing the point velocity of one team to another. This can support the myth that a higher velocity is an indication of a higher-performing team.
  • Paying too much attention to the points and the velocity. These values are only meant to serve the engineers on the team, and are not intended as a way for managers or product owners to do resource planning.

Because of all this confusion, there has been a justifiable backlash against point tracking in some agile circles. A few people have called for eliminating points altogether, arguing that they are not only confusing for the people using them, but that tracking and estimating them is a distraction from the work the team should really be doing.

The interesting thing about these arguments is that they frequently replace the traditional point system with an alternative approach that still involves training the product owners and the team to use some other unique metric to balance story weight and measure out a reasonable amount that everyone can agree to.

In some cases, teams are encouraged to just count the number of stories, on the optimistic assumption that the stories as written would all estimate out to be comparable if points were being used. Of course, the reason for the point estimation exercise is that it is virtually impossible for a product owner and a team to agree on what constitutes a relatively equivalent story without a great deal of experience working and estimating together.

In other proposals, teams are instructed to use less granular approaches such as t-shirt sizing (small, medium, large, and extra-large) or some other limited scale instead of a numerical Fibonacci point system. Some people also favor a continuous release cycle that avoids the quantum concept of sprints in favor of a constant feed of stories, moving closer to a Kanban approach.

With a team that is self-aware and experienced enough at working together with a scrum mentality, many of these methods might work. Agile can work without points or estimation. But to my mind, the key advantage of that approach comes down to avoiding the competitive associations people may have with the terms point and velocity. In every successful case I have studied where point estimation was abandoned, the agile leader still needed to coach the product owners and the team actively to make sure that stories are sized relative to each other, so the team can commit to a reasonable backlog.

Despite the challenges associated with the terminology, I would argue that the combination of point estimation and velocity tracking provides the most straightforward path to helping a team learn how to commit wholeheartedly and conscientiously to stories that result in shippable product features.

But scrum is not a drop-in replacement for the value of solid project management. There are good reasons to use other tools and techniques in concert with points and velocity to track other metrics for the team.

When to Use Points, Days, and Hours

The basic thing to remember is that points are a subjective and relative way of estimating forward, while time is an objective way of evaluating backward. As long as you keep this distinction in mind, it will be easier to respond when people get confused about when to use which.

Points and velocity allow the team to estimate and commit to a backlog of feature stories that add value to the product for the customer.

Hours can help management track the time that was spent on completing feature stories, and who was doing the work.

Hours are useful for time-boxing meetings, spikes, and tasks that may be necessary, but these need to fit within a budget.

Hours can be used to help a team plan out the individual sub-tasks they may need to perform as they break down a story.

Hours or days are useful for looking back on the actual amount of time it took the team to fix a bug, research a new concept, or implement a development tool improvement.

Hours or days are also practical for keeping track of work that wasn’t agreed to as part of the sprint, but that had to be completed during the sprint due to escalations and high-priority customer and product support issues.

Let’s Not Abandon Points

Maybe some teams would see a benefit if they stopped calling their estimation metric points, and avoided using words like velocity to track the sustainability of their development practice. Perhaps, just to make things clear, we could highlight the distinction by calling them story points and story velocity explicitly, so that people don’t get confused and try to use estimation as a way to track the total time and effort invested by the team.

There is value to knowing how much work the team can handle, regardless of whether they’re working on story points, chores, tasks, spikes, or fixing bugs. Days may be a sufficiently accurate metric for looking at how much work the team is able to do as a whole. Managers can easily calculate that every day at standup, just by keeping track of how much work of any kind was completed each day. And if more accurate tracking of other work is needed, for the sake of billing clients or other reasons, there are many convenient time tracking tools that can be installed on people’s computers that can keep track of how the team’s hours are actually spent.

Of course, the team’s actual story velocity will only be influenced by how much of the work that was done was actually part of the stories in the sprint. Remember, story velocity should be a measure of how quickly the team is able to accomplish the stories necessary to move the product forward for the customer, in relative and subjective story points that help the team learn how to estimate their ability to handle new stories as they come up. When points and velocity are forced to perform double duty as tools to measure how effective the team is overall at getting work done, they can lose their value as a tool to help the team learn how to estimate better.

Has your team experienced confusion in the use of points? Have you designed an alternative to avoid the misinterpretation of velocity? Please let me know below.

Frequently Asked Questions (FAQs) about Agile Confusion Points

What are the common points of confusion in Agile methodology?

Agile methodology, while highly effective, can often lead to confusion, especially for those new to it. Common points of confusion include understanding the roles and responsibilities within an Agile team, the difference between various Agile frameworks like Scrum and Kanban, the concept of continuous delivery, and the importance of customer collaboration over contract negotiation. It’s crucial to clarify these points to ensure the successful implementation of Agile.

How does Agile differ from traditional project management methods?

Agile differs significantly from traditional project management methods. While traditional methods follow a linear approach, Agile adopts an iterative approach, allowing for flexibility and adaptability. Traditional methods often have a fixed scope, while Agile encourages changes and improvements throughout the project lifecycle.

What is the role of a Scrum Master in Agile?

The Scrum Master in Agile plays a crucial role. They act as a facilitator for the team and the product owner. They help remove any obstacles that the team might face, coach the team in Agile practices, and ensure that the Scrum process is followed.

How does Agile handle changes in project requirements?

Agile is designed to handle changes efficiently. It encourages regular feedback and allows for changes to be incorporated at any stage of the project. This flexibility ensures that the final product meets the customer’s needs and expectations.

What is the importance of customer collaboration in Agile?

Customer collaboration is a key principle in Agile. It emphasizes the need for regular interaction with the customer to understand their requirements better, get feedback, and make necessary changes. This approach ensures that the product developed aligns with the customer’s needs and expectations.

What are the common Agile frameworks and how do they differ?

The common Agile frameworks include Scrum, Kanban, and Extreme Programming (XP). While Scrum is best suited for complex projects requiring frequent changes, Kanban is ideal for projects with a continuous flow of work. XP, on the other hand, focuses on improving software quality and responsiveness to changing customer requirements.

How does Agile ensure quality?

Agile ensures quality through continuous testing and integration. It encourages regular reviews and inspections to identify and rectify errors early in the development process. This approach helps in maintaining high-quality standards throughout the project.

What is the role of a Product Owner in Agile?

The Product Owner in Agile is responsible for defining and prioritizing the product backlog. They work closely with the team to ensure that the product developed aligns with the customer’s needs and business goals.

How does Agile manage project risks?

Agile manages project risks by promoting transparency and encouraging early and frequent feedback. It allows for risks to be identified and addressed early in the project, thereby reducing their impact.

What is the importance of self-organizing teams in Agile?

Self-organizing teams are a key element in Agile. They are empowered to make decisions and manage their work, which fosters creativity, innovation, and accountability. This approach leads to higher productivity and better quality products.

M. David GreenM. David Green
View Author

I've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.

Agileagile methodologypointsscrumtomtvelocity
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week