Episode 6: Transparency

A common question that any manager or executive might ask (or be asked for that matter) is: “How well is the team doing?”. That’s a fair question which leads us to the 3rd pillar of Scrum: Transparency. Scrum provides all the means to make the work done on the product, processes and problems as transparent as possible in order to improve on them as quickly as possible. Transparency also allows for the growth of trust; whether it’s within the scrum team, between multiple teams or between the teams and consecutive levels of management that exist in the company. Vice versa, trust also contributes to better transparency, by building a safe environment for the teams to expose their success and failure. A few artefacts which contribute to building better transparency are: team metrics, Definition of Ready (DoR) and Definition of Done (DoD).

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.

Dariusz Szlęk

Darek is a certified Scrum Master for nearly 6 years and had worked as part of the Hycom team in a large e-commerce project for Deutsche Telekom. During (nearly) 5 years on the project, he was a Scrum Master to 1-3 teams and a project manager while building the customer-facing portal of the largest European telecommunications provider: www.telekom.de. Darek focuses his experience on continuous improvement in agile product delivery processes, building stable long-living teams and promoting agile culture in business organizations.


You might also like

  • Episode 5: Scaling up

    In Episode 2, I had discussed the pros and cons of running a project using the Scrum framework. If implemented properly, not only can it lead to multiple rewarding aspects for the project but can also help shaping an agile mindset.

    read more
  • Episode 4: 4 out of 5

    One question regarding Scrum that comes up quite often, whether it’s during an academic discussion with my “colleagues from the industry” or just some theoretical pondering of my own, is: if you had to eliminate 1 Scrum event – which one would it be?

    read more
  • Episode 3: Setup & kick-off

    So, you have now decided to give Scrum a try. You have identified a business opportunity and you have a vague product vision that will allow you to seize that opportunity if acted upon within a defined time period.

    read more

let's make something great together!

start a project