Team velocity or functional velocity

When using Scrum, a team engage itself on the workload according to its past velocity. The goal is to stay reasonable regarding the workload to do during the sprint. Depending on the teams, this velocity maps all the activities or it is restricted to only functional activities.

Take into account all the activities

An agile team performs different kind of activities : adding functionalities (user stories), correcting failing functionalities (bugs), technical activities (“technical stories”) or correction of technical debt (refactoring). All that is very well sum up into the next diagram as defined by Philippe Krutchen, and next used by Alex Boutin in French 2015 Scrum Day.

Analogy building domain

In Agile, we are often wary of the field of construction: Gant diagram planification, analogy with project management. We can still keep this analogy as we still find unexpectations, corrections and changes in needs. The technical debt exists also in painting. For example, when we make a color paint mix de peinture by hand, if we do not precisely mesure quantities, we will never be able to reproduce exactly the same color.

If we compare with a paint site, setting up the technical infrastructure corresponds to the installation the site: plastic sheeting to cover the floor and the irremovable parts, removal of moving parts (caches, light spot), … At the opposite, the cleaning of the site before delivery corresponds to the dissolution of the team with the clean archiving of the technical infrastructure.

As in computer, the error corrections (here, the repetitions of paint) are the responsibility of the service provider.

A backlog represents the team activities

When the Product Backlog represents exhaustively all the team activities, it contains items from each of the four types. Each is evaluated according to the same scale. The Product Owner shall sort those items by taking into account interests from all Stakeholders, including the agile team.

Even if it is highly recommended to keep some functional stuff every sprint, the quantity may highly vary from a sprint to another and this is depends on the priorities of those activities. The below cons diagram shows a strong refactoring need in sprint 7 that is made instead of functional stuff.

Restriction to functional activities

Unfortunately, this consideration stay most often theoretical. For stakeholders ad the representative, the Product Owner, the point is to measure  project progress from a functional point of view. We can then introduce another velocity: the functional velocity. It takes into account only functional activities. It corresponds correctly to the progress of the functional development of the product (green ligne on the diagrams).

The risk is to “mask” non-functional works by affecting a constant percentage of the effort to technical activities and to defaults correction. The part of those various activities into this margin may vary according to needs. And it’s the team who arbitrate the priorisation  work without asking to the Product Owner, when the Scrum Master does not behave as a Product Owner for technical activities! The Le diagramme below cons reproduce the same functional velocity as before. For non-functional activities, priority is given to default correction (same charge as before), by setting a volume being proportional to the functional velocity. We then see that the refactoring part, previously considered as necessary, is highly reduiced.

In such a case, non-functional activities are hidden: they are never demonstrated.

In the case of a subcontracting contract, we may reach a fixed contracted velocity. In theory, with the fixed percentage, the real velocity is fixed. In practice, we know that, given the difficulties, the team velocity vary a little from a sprint to another.

     

The second diagram reproduce the initial real velocity in a context of fixed contracted functional velocity.

This solution accumulate cons. More than the team arbitration and its opacity, we loose the the interest for velocity as a monitoring tool for the team. The team will tend to finish all the functional items to respect the contract. Adjustment will be done on the technical part. When there is a need for refactoring (buyback of technical debt) or for settings up technical tools (for example, enforce automatic tests system), the team favor the functional part.

Visualize the functional part differently

Another way to follow the functional progress consists in using a Cumulative Flow Chart, being dedicated to feature adding.

This diagram visually gives a very good picture of the part for each various activities.

 

Recommandations

We should really consider all the done works, keep their mastership by the Product Owner. If she does not understand them, the Scrum Master role is to help her to understand the importance of those works for the team.

Tagged with:
 

Leave a Reply

Your email address will not be published. Required fields are marked *

PageLines