Points of Confusion in Agile
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.