Velocity

The internet offers a vast amount of information that we do not intend to replicate. Therefore, we provide a brief summary, highlighting a few points not typically covered:

The term "Velocity" is used instead of "Speed" to align with physics terminology, as it represents a vector rather than a scalar quantity. Velocity refers to speed in a specific direction. For instance, moving in the wrong direction at a high speed would result in a negative velocity.
In agile teams, velocity serves as a measure of the amount of work a team can accomplish within a single iteration or sprint, typically lasting two weeks. It's important to note that we avoid referring to velocity as a measure of productivity (the reasons for this are beyond the scope of this discussion, but the following points may provide some insights).
Velocity is the sum of all Story Points (or a similar measure of effort) completed during an iteration.

According to the true, original definition of velocity, Story Points should only be assigned to work items that contribute to the team's progress towards the end goal. Tasks such as bug fixing, which have already been deemed completed and accounted for in terms of points, should not carry any additional Story Points. Similarly, other tasks or activities that do not contribute directly to the team's goal should not be assigned Story Point estimates. We explore this more below.

It's worth noting that this point can be debated, as the choice depends on what is considered most important to measure and forecast.
Historical velocity can be used by a team and its stakeholders to track progress and estimate completion dates, often referred to as "Forecasting." This information is typically visualised on a Burn-up or Burn-down chart.
At VFS, we prefer having a chart of historical velocity displayed alongside our burn-down or burn-up chart on our scrum wall. Please refer to the example below:

By incorporating these concepts, teams can gain insights into their overall progress and make informed decisions based on their historical velocity and current progress. visualisation. Whilst these charts are usually created automatically within tools such as Jira, they are very easy to create manually, even hand drawing and updating them.

Which tasks should we assign Story Points to?

Let's consider another example of Backlog Items that may not require Story Point estimates (though there is room for debate):

Take, for instance, Technical Debt repayment tasks. If a team dedicates an entire sprint to working on these tasks and successfully completes them, the team's velocity for that sprint would be zero. This zero velocity accurately reflects the lack of progress towards a typical product development goal, such as the release of a new feature. However, the work performed is undeniably valuable... right? Otherwise, it wouldn't have been undertaken in the first place.

By adhering to the original definition of technical debt* as something that hinders progress, addressing it allows the team to develop and release faster in future sprints. Furthermore, if a team has been taking shortcuts and accruing tech debt, it has been going at a false fast pace. Therefore, a sprint with a low or even zero velocity serves as a means to reset the average velocity and establish a more realistic reflection of a sustainable pace.

In summary, while Technical Debt repayment tasks may not contribute directly to the immediate progress of feature releases, they play a vital role in enhancing future development speed and maintaining a sustainable pace. Therefore, assigning Story Points to such tasks is a matter of determining the most accurate representation of progress and aligning with the team's goals.

Sustainable and Predictable?

To ensure a sustainable pace, Historical Velocity serves two key purposes:

Guiding sprint planning and short-term forecasting
Extrapolating progress for multiple future sprints.

When velocity is calculated using only User Stories estimates, it helps set realistic future achievements towards the primary product or project goals. Other work done should be recorded, just not as Story Points*.

But how do we estimate all the different types of Backlog Item (BLI) on the product backlog? This is where the this original rule has become contentious. Depending on the make up of your product backlog, what historical velocity is used for and what information you need to radiate, you may want to make your own rules.....that's fine. But first consider if all these reasons are valid reasons for assigning Story Point estimates to more than just User Stories.

*Often, when using tools such as Jira, Story Points may be used as the estimating mechanism and the Backlog items are categorised or labelled to allow velocity to be calculated for each category or label of work.

Velocity & The Cone of Uncertainty

Uncertainty is reduced by driving out variability, to paraphrase Steve McConnell. Variability can be found lurking and undermining all aspects of projects and product development. Variability exists within the estimation process of agile software development teams and you should expect story pointing estimations and sprint planning estimations to have a large range initially before settling down over time (if actions are taken to improve).

A reasonably common technique for driving out variability in estimations is to track the estimated effort versus the actual. This can be quite time consuming if done at a granular level. Doing it on the sprint commitment or forecast beforehand versus what was actually achieved is a very lightweight approach.

Any change in team members, new technology or tooling will introduce variability.

Further Reading:

Here are our recommended external further reading resources:

*Technical Debt: Many online definitions suggest that it is simply the implied cost of future work to tidy up and improve shortcuts and user priorities over other business requirements related to the maintainability and other "Cost of Ownership" factors. However, that's not quite correct. There are several reasons why a debt could be written off, and the same is true in the software world. For example, when a chunk of code is retired or replaced with a third party service. Strictly speaking the analogy to financial debt is that we are burdened with ongoing interest and continual debt repayments. In the software world, Tech Debt is that code, software design, lack of unit tests or tooling issue, to name just a few) that is slowing us down today...we are having to expend more effort right now that we otherwise should, to be able to achieve our objectives today.

Programmer Ward Cunningham originated the definition of technical debt as we know it in a 1992 article articulating that while the enterprise may save money in the short term by coding in this fashion, in the long run, “interest” from the tech debt, as with monetary debt, will accumulate, making the initial problem increasingly costly to fix as time goes on. This suggests that whilst it may not be slowing us down today, the effort required to resolve the issue in the future is growing. An example of how this can happen is when new code is written on top of poor code and when the poor code is rewritten, all the new code sitting on top of it will also need to be rewritten.

Tech debt can also be generated unintentionally — sloppy programming, cutting corners or an abruptly expedited schedule are all common problems that every enterprise faces. Some would argue that this does not constitute tech debt. Others would consider it technical debt because it is hampering our ability to go as fast as we otherwise could, and an investment, a payback, would help us go faster in the future.

VFS suggest distinguishing between the issues that are impeding us today from those that may in the future (debt vs risk vs investment). For example, the business and the product strategy strongly suggest that our software architecture is not a good fit for probable new needs. We can wait and resolve the issue when it is absolutely needed. But what if the solution involves the procurement of a third party service for example? What if it is a major undertaking to introduce a new technology into your tech estate? The lead time to get agreements in place, to integrate with it and gain confidence that the integrated systems are operating correctly may cause unnecessary and significant delays in achieving the product and business goals. It wasn't addressed just in time, it was a done, just too late. It slowed us down unnecesarily and it may be the result of previous tactical prioritisations, such as choosing user features over these technology foundations. Maybe we consider it as tech debt at this point in time? Maybe not. But it went from an identified risk to an identified investment need and then impacted us as a debt does.

If we are to address this type of issue proactively, actually just in time, we may choose to refer to this as a Tech Investment. The term has different connotations. And it makes sense to some, when it isn't directly related to items currently on the Product Backlog or Roadmap but some effort to explore it is prudent.