What are "Consumed Story Points" in Trello?

Question

Some Scrum add-ons allow you to enter both estimated story points and consumed story points. What are consumed story points and how do you measure/estimate them?

Answer 1

Consumed Story Points: An Agile Anti-Pattern

"Consumed points" are a sort of burn-down metric that some practitioners use to track progress of a story against its original estimates. It's intended to show percentage of work completed, estimate overruns, or to reduce the need for collaborative communication about story status.

In my coaching practice the use of consumed points is considered a Scrum/Kanban anti-pattern. Story point estimates are invalid outside the estimation process itself, and have no utility outside Sprint Planning or Release Planning. They should be treated as ephemeral values, and should be:

1. Created, reviewed, or revised during Sprint Planning.
2. Discussed during Sprint Retrospectives as a way of refining the team's estimation and planning process.
3. Discarded along with the time box, except as an aggregated total for use in the velocity metric.

Let's look at a concrete example, and discuss why people may use consumed points and what they should do instead.

A Worked Example

Let's say you're using Trello with the popular Scrum for Trello Chrome plugin. You might have a board like this:

Estimating Percent Complete

In the Work in Progress column, the story is estimated at five story points, and the team has guesstimated that 50% of the forecasted work has been completed. Theoretically, that means the story in the second column is half-done.

But wait! In Scrum, as in most successful agile frameworks, each story is either done or not-done. The whole framework is designed to get away from false precision and pointless status reports claiming that 60% of something is 80% done. In Scrum, a story is either 100% done (per the Definition of Done, of course!) at the end of the Sprint, or it is simply incomplete and must be returned to the Product Backlog unfinished, where it may be rewritten, reprioritized, rescheduled, and replanned.

So, why does anyone use consumed points? The people who do it often have reasons, and those reasons generally fall into a couple of common categories.

1. Their process isn't fully collaborative, so "consumed points" are a way to avoid more meaningful status updates. Unfortunately, "I'm 50% done" isn't particularly helpful, but "I'm working on a story that I can't complete unless Alice is done with her story to embiggen the widget" would be clear and actionable.
2. The Scrum Master, Product Owner, or an external stakeholder is trying to replace burn-down charts, daily standups, or other ceremonies and artifacts with metrics on a card. Story points are a planning tool, not a performance metric, so using them for anything else is inherently a misuse of the metric that yields unreliable information.
3. The team and its stakeholders don't fully understand estimates or forecasting, and are trying to tie level-of-effort estimates to labor hours. Their underlying assumption is that story points have intrinsic conversion rates to time, and that each story will have a strictly linear progression from started 🔜 finished. Neither is the case.

When done properly, a Sprint Backlog is decomposed into done or not-done items that can be measured in the Sprint Burn-Down. This is a much more accurate view of how much work remains in the current Sprint. In contrast, percent-complete of stories is yet another subjective proxy metric, and functions as an inexact secondary forecast. For example, if you say:

The work-in-progress story is 50% done, so I'm estimating that it will take me another 5 days to complete it.

all you've accomplished is adding a new time-based (and largely unsubstantiated) forecast on top of the original level-of-effort forecast. Experience shows that this is rarely accurate, and almost never worth the time to track. "Done" or "not-done" are the coins of the realm in agile frameworks!

Tracking Overruns and Inaccurate Estimates

The other use case is demonstrated by the third card, located in the Done column. In that card, you can see that the team estimated the story as three story points, but later claim that it took eight story points to complete.

While there is nothing wrong with pointing out in a Sprint Retrospective that a user story was grossly underestimated and using the experience to improve the team's estimation and planning process next time around, the utility value of formally tracking the magnitude of the mis-estimation is zero.

In a Retrospective, it's perfectly reasonable to say something like:

We all thought that this story was a 3 because...but it turns out we didn't think through the dependencies on foo, bar, and baz. Plus, we had to ensmallen the whatnot in order to complete the story, and we didn't think to create a Sprint Backlog item for that or include that in our estimates. Maybe we need to decompose stories like this better during Sprint Planning.

However, a Sprint is an ephemeral time box. Once the Sprint is over, it's gone forever. Either the Sprint Goal was met, or it was not. Either a story was completed in that Sprint, or it was not. Six months later, does it matter whether a given story was easier or harder to complete than originally planned? Of course not.

The real reasons people use this post-hoc metric are:

1. The team is being "held accountable" by the organization to show how much effort they're putting in. This is especially common when Sprint Goals aren't met, and the team wants to say "We didn't complete all the stories needed to meet the Sprint Goal, but look how much effort we out in on Story X!"
2. The team is improperly treating velocity as a measure of productivity, rather than a measure of historical team capacity, and trying to game the metric to improve the optics. "We estimated this story at 3 points, but it really took 8, so we really did 25 story points rather than 20 this Sprint! We're super performers; please don't fire us!"
3. Upper management is improperly treating velocity as a performance target rather than a forecasting tool, and driving the team to take on more work than may be sustainable. The original estimate may have been set by leadership rather than the team, or the story was pushed into the Sprint by stakeholders without sufficient decomposition. Do you really want to track separate velocity metrics to cover up a deeper process problem?

Review, Don't Track

There are several schools of thought about whether teams should ever adjust story points within a Sprint. This is a complex topic outside the scope of this answer, but the overly-simplistic answer is that you're generally better off leaving your initial estimates alone if your goal is to improve your process. It's much better (from a process point of view) to say "Hey, we mis-estimated! Let's fix that next time!" rather than constantly moving the cheese.

Velocity is a metric that converges towards a mean over time. As long as you continue to improve the estimation process, the accuracy of your velocity as a predictor of Sprint capacity will improve. The value of velocity is in its ability to predict capacity despite perturbations and periodicity, so there is almost never a good reason to retcon the results of an individual Sprint—and in fact, numerous reasons not to do so!

Agile teams should be small enough, and Scrum Sprints short enough, that formal tracking of deviations from the planning estimate should not be necessary. As this data should never be used outside of a single Sprint time box, retaining this data beyond the time box is also unnecessary.

To sum up, it's worth reviewing discrepencies in estimates, or identifying process impediments that kept a story from being 100% done. However, tracking this data as a first-class element on a story card is very much an anti-pattern.