Maintaining accurate metrics for observing the team’s performance is an extremely valuable part of any scrum master’s work, as well as that of any mature scrum team. Many teams limit their metrics to two fundamental ones: velocity and capacity; while that may prove to be sufficient for some teams (every team is different, hence metrics is yet another relative topic), I would recommend to consider the following 5 metrics and give them a try at least at the beginning:
Standard velocity – refers to what the team actually delivers every sprint, usually expressed in story points
Average velocity – average taken from the last 6-12 sprints (depending on the duration of the sprint)
Team capacity – team availability in a given sprint, expressed in %, where 100% is the full duration of the sprint x number of dev team members
100% scaled velocity – standard sprint velocity scaled up to a 100% team capacity, representing the team’s velocity sprint to sprint regardless of their loss of availability
Average 100% scaled velocity – average taken from the last 6-12 sprints (depending on the duration of the sprint)
The best way to enforce transparency is to keep all of these metrics visible and available to everyone in the working environment; it shows that: “Hey! We’ve got nothing to hide!” All of them can show us various information about the team’s performance. Standard and average velocity will be most crucial to the product owner because they actually represent how much/fast the team is able to deliver. The PO would not care much for information regarding what the team could be delivering if some members were not on holidays, or were not sick… That information, scaled velocity and its average are more valuable to the scrum master and team itself to observe how their performance shapes up against a constant team availability variable. Personally, I find average velocities much more valuable, especially when the product increment is not being released every sprint but in defined releases. For less mature or less stable teams, where the whole sprint commitment is not being regularly delivered, it provides a mean to see how far they can get in a defined period of time. Standard velocity vs. 100% scaled velocity gives us valuable information regarding how the team is able to perform even if it temporarily losses its significant part and taking into account the variating team capacity, the scaled velocity allows us to observe how the team is evolving with aim to reach a stable velocity in time, where the distracting factor of capacity is excluded.
The next two tools which have a positive impact on the overall transparency are well known definitions: that of Ready and of Done. While formally only the Definition of “Done” is actually mentioned in the Scrum Guide, both play a significant role in maintaining backlog transparency for the product and surrounding project environment.
Definition of “Ready” – should specify all prerequisites necessary for a backlog item to become ready for being worked by the team, this may include any external elements to the team’s work, any agreements or confirmations, etc.
Definition of “Done” – should specify all requirements that must be met for a backlog item to be considered as completed and a part of the potentially releasable product increment
Both of these definitions must be clearly understood by all of the stakeholders. The definitions usually apply to a single product, and while they may be used as a reference for building similar products, it is highly recommended that they be evaluated and updated accordingly to the product’s needs. When more than one team is working on a product, it is especially important that all the teams adhere to these definitions and work with respect to them as they were established (should’ve been established involving all teams). While not mandatory, it is possible to expand these definitions on a per team basis, however the definitions should never be reduced from their initial state by any team working on the product. Sometimes it can happen that a team identifies a useful point to incorporate into either definition and make it more bulletproof for the sake of better product quality – such approach is more than welcome; occasionally the definitions may be evaluated by the teams and product owner to expand their base, what is even expected according to the Scrum Guide, as the teams become more proficient and mature.
All in all, the aspect of transparency on multiple levels in a project working with respect to the Scrum framework and its principles, is one of the key factors driving its success. The abovementioned artefacts constitute only a fraction of the available means to build a product in a transparent and trustful atmosphere. Nevertheless, I highly encourage you to make proper use of them while building your product and to look for even better ways of embracing transparency and culture of trust in your organization.
If you are wondering how to implement Agile into the development of your IT products contact us: