Should velocity increase with time?

Question

Some scrum masters are concerned with "bumping up" a team's velocity during a sprint, as if a higher velocity is better. But points are a relative measure of the work that a team needs to do for feature X; they are not high or low, they're just more or less than some other feature the team arbitrarily chose as a point of reference. What's important is that you know what your velocity is, however many points that is.

If points are effort, you don't make a greater effort with time. You make the same effort, but it is more productive. So a story that was estimated at five points when the team first formed could eventually be estimated as three or two points as the team increases its skills.

Is that correct? I don't see a consensus on whether points measure complexity or effort, but either way it seems to me that as time passes, the perceived effort or complexity of a task will go down and you will be able to fit more of them in a sprint, thus keeping your velocity constant.

Answer 1

TL;DR

Should velocity increase with time?

The simplistic answer is that a project's velocity should only increase until the team has developed a stable, predictable cadence that can be maintained over time. There are a few caveats, of course, but it's a solid rule of thumb.

Targeting an indefinite upward trend on velocity is a "project smell" that the velocity metric is being misused or misunderstood. Expecting such a trend is often a symptom of management's desire to press a "go faster" button without respecting the sustainable-capacity limits of a project or team.

Velocity Measures/Forecasts Capacity

Velocity is a measure of a team's historical capacity, rather than a directly-correlated measure of the team's speed or productivity. It should be used primarily during Sprint Planning to forecast Sprint Backlog capacity for the upcoming Sprint.

A team's capacity can certainly change over time: capacity can go down during holiday periods or reorganizations, or go up as teams gain domain knowledge, leverage iterative improvements to their test-driven designs, or pay down technical debt.

However, it's a fallacy to assume that capacity can or should have an upward trend. Even though the cone of uncertainty narrows later in a project, the cost of technical debt and refactorings generally increase, and these factors consume team capacity as well. In addition, it is not uncommon for the complexity of user stories to increase over time as the low-hanging fruit is picked from the Product Backlog. Again, this added complexity will consume a commensurate amount of capacity from the team.

The goal of Scrum (and iterative agile development in general) is to have a sustainable and predictable development cadence. As such, it is generally better to aim for consistent velocity over time rather than for increasing velocity.

Answer 2

Story Points measure a combination of Complexity and Effort, which is what makes them hard for people to understand. Risk, uncertainty are likely also components that are part of the estimate.

In the end velocity is a measure of what you have delivered in the past (few) sprint(s). It's an indicator of what you can expect to deliver next sprint when nothing changes much.

We do see that Scrum teams improve over time however, they get better at what they do, they automate things that take up a lot of time each sprint, they increase their knowledge of the domain and they start to be able to re-use code elements from previous sprints to build on top of.

As such it's normal to see teams increase their velocity over time. Often that velocity reaches a ceiling, their maximum capability given the current circumstances, and won't be able to start climbing again without a major event. That event could be training, changes to the way of working, a new team member with a key skillset or a switch from one technology to another (or simply an upgrade from vold to vnew).

Most teams pick a couple of reference stories. Some just pick their 1, 5 or 8. Other teams pick a 5 and a 20. it doesn't really matter what they pick. Given these reference points you compare the other stories to the original request. As such, the number of story points between two stories is often equal, even though the exact amount of effort has reduced drastically over time. This is why a team may be able to increase its velocity from 40 to 200 over time.

When a team doesn't feel they have enough granularity in the lower reaches of their story points, they may opt to pick a new 5 and adjust all the other items on the backlog accordingly.

Remember that increasing velocity is not something which we should try to encourage all the time, treating the velocity as a metric will not help the teams understanding of what they can actually do and usually leads to bad behavior when it comes to estimating. Instead, as a scrum master you should focus on removing waste and increasing value delivered per sprint. If the team has the same focus, their velocity will rise as a result.

Answer 3

Story points are a relative measure of effort. Over time a team a team may get better at doing things. But that does not necessarily mean a 5 point story becomes a 3 point story. Here is an example:

Story X involves writing a search feature on a web page and is estimated by the team as 5 points. Story Y is a setting to hide pictures on a web page and it is estimated by the team as 3 points because relative to Story X it is smaller.

Now say the team improves massively in the next year, so that they can do both Story X and Story Y in half the time they originally took. But note that the relative size of the two stories has not changed. For this reason the team might still estimate them as 5 points and 3 points respectively.

However, if the team improved their ability to do Story X but did not improve their ability to do Story Y then the relative sizes would change. They could, perhaps, both become 3 point stories.

A team can decide to reset their baseline for what a story point is. The downside with this is that they will lose some value of their velocity history as it will no longer be a good guide of what their capacity is for future sprints. But there is nothing to stop a team doing this.

The important thing to remember is that velocity is purely about measuring the capacity of future sprints. The numbers themselves are arbitrary, but the relative sizes of the numbers are important.

Answer 4

You're right: Story points are essentially about effort. By taking them as a measure of the throughput of your team, and given a stable team and a stable environment, you should expect velocity to stabilize over time, not increase (although an increase could be an effect of such process).

Story points are not about the complexity of developing a feature; they are about the effort required to develop a feature.

https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity