When planning releases, it’s important to understand where team effort is being spent. We want the team to make things as transparent as possible, but we also need to be aware of how this affects the rate at which features can be developed.

It’s a challenge to get teams to deliver consistently and be able to demonstrate this with a solid velocity. It's great to get them into the habit of thinking that everything is a story—features, defects, and technical debt. It's best that we measure this and declare it rather than hide it away.

I don't want to make this process even more difficult, but what we need to keep an eye on is the velocity of features. It's great that the team has a solid and consistent total velocity, but from a project management perspective, what I'm primarily interested in is how many story points we got done on new features. Essentially, this is:

V_features = V_total – V_defects – V_{technical debt}

This is important because when determining the minimum viable product (MVP) for a release, it is nearly always measured in features. There may be cases when the MVP includes essential defects, but the features are far more likely to be the key for a release.

The MVP will describe the features required to be able to market compelling reasons to buy the product, so features are more important than defects and technical debt. How they are compared is decided by the product owner and key stakeholders, and this can provide options for a project manager—or even be advantageous.

For planning, if we can assume a certain amount will be spent on defects and technical debt, then we can calculate V_features. For example, let’s say a team has an average velocity of 40, and on average they spend 8 story points on defects and 5 story points on technical debt:

V_features = 40 – 8 – 5 = 27

It starts getting difficult when dealing with averages, and 27 sounds quite precise, so we need to be careful when using these figures. But let’s say that the expected release payload for this team is 300 story points and we have 10 iterations. We can do a quick calculation and say that it’s going to be OK if the team could drop everything and just produce features:

40 x 10 = 400

But assuming that they have defects and technical debt to deal with, then they’re challenged:

27 x 10 = 270

I like to think of this as being “between two watermarks,” as shown in the diagram below.

The high watermark is what the team could achieve if it dropped everything. If the target payload were 500 story points, then the project manager should raise serious concern, as this is even above the high watermark. The low watermark is what the team can expect to achieve, taking into account defects and technical debt. If the target payload is 200 story points, then no concern is necessary, as this looks totally achievable unless circumstances change.

If the payload moves above the high watermark, then warning bells should ring. If the payload moves below the low watermark, then the team should be able to adopt their usual behavior.

If the target payload is between these watermarks, this is where a certain amount of expectation-setting and negotiation should come in handy. In these situations I think it’s best to set expectations with stakeholders and explain to them that it may be necessary to reduce the effort in fixing defects for a few iterations. On the plus side, this allows the team to focus on features; on the minus side, this may result in a lower level of quality, at least for the period when the team adopted this behavior.

This is a better conversation to have than the stakeholders assuming the team will increase velocity and the target payload will be achieved without altering this behavior. Once the team starts working on the payload, the estimates will be revised as more is understood about the stories that make up the payload, so it’s important for the project manager to do this watermark calculation as often as necessary. I would recommend updating this calculation whenever there are any significant changes to the payload, delivered points, or risk factors.

By using these high and low watermarks, a project manager can determine a suitable approach to take when setting expectations with stakeholders and determining whether it is necessary to alter team behavior to focus more on getting those all-important features into a release.

* Any views expressed within this article are Dave Browett's and do not necessarily reflect those of his employer.