Transparency in Scrum

Scrum is based on empiricism, which is based on three most important aspects (also known as the three pillars shown in the figure below) and supports each implementation of empirical process control: transparency, inspection and adaptation.

When scrum teams embody and practice the values of commitment, courage, focus, openness and respect, Scrum’s pillars of transparency, inspection and adaptation emerge and build trust for everyone. Scrum team members learn and explore these values when dealing with Scrum roles, events, and artifacts.

Ensure Transparency — Scrum Team

Scrum enhances transparency inside and outside the team. Transparency is critical to the Scrum process because it allows everyone to see and understand what is really happening in each sprint, leading to greater and better communication and trust within the team.

Teams can be transparent in many ways. Here I list some things we can do to achieve it:

Work Closer and Feedback faster

Scrum teams should be transparent in the way they work: bring stakeholders closer together, work with them on a daily basis, let feedback flow in both directions, and share the risk of taking one direction or the other.

Make Work Progress More Visible

Teams can make progress visible: burndown charts and whiteboards are the traditional way to show the progress of sprint goals. These simple tools can show the progress of each stage of the plan, from sprint to vision, which can effectively reduce “when can it be completed?” Dialogue.

The team can make progress visible: burn down charts and a whiteboard are the traditional methods for showing progress against sprint goals. A simple report to show progress at all levels of planning, from sprint all the way up to vision, can be incredibly effective at reducing the number of ‘when will it be done?’ conversations.

Free Flow of Updated Information

Information needs to travel in both directions. Stakeholders and those in product roles, especially those who work directly with a team, must be transparent too. Product direction in the form of roadmaps, release plans or definition of done can be made visible to the team so that they are aware of the overarching goals and expectations they committed to deliver on.

Scrum Master can help

In Scrum, it’s not the team that works for the Scrum Master, it’s the Scrum Master who strives to facilitate the work of the development team. The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the events and artifacts are completely transparent. The Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency. A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.

Transparency in Events

Sprint is a container for all other events and each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

The transparency is the first significant aspects in the Scrum process that must be visible to those responsible for the outcome. Transparency requires those aspects be defined by in its day-to-day activities and artifacts so the team can share a common understanding of what is being seen.

For example:

Sprint Planning Meeting

The Sprint Planning Meeting is held at the start of the Sprint to understand and document the Sprint Backlog Items. It is conducted to make sure that everyone involved undoubtedly knows what is to be done on his/her part to contribute to the development of that particular incremental iteration of the

Daily Scrum Standup Meeting

The Daily Scrum is focused on the day-to-day reflection of the team’s contributions to the particular Sprint. It answers three things:

  • What I have developed for last 24 hours to meet the daily Sprint goal?
  • What will I do today in order to achieve my next Sprint goal?
  • What the impediments are in yesterday’s work that hinder my goal achievement?

Daily Scrum is very crucial in terms of sharing all these things without having the fear to admit one’s mistakes. If unshared, the project gets complicated, causing delays, and eventually risks of project failures.

Sprint Review Meeting

The Sprint Review Meeting is conducted at the end of a Sprint to reflect what has been done to complete it as an increment of the product. The team invites the stakeholders to get their feedback on the Sprint, which is incorporated into the Product Backlog by the Product Owner, to bring improvements in the next Sprints.

Sprint Retrospective Meeting

The Sprint Retrospective is held to inspect the last Sprint in order of its people, interactions, process & tools, and to adopt improvement measures from this Sprint to develop the next Sprint. It all requires transparency in reporting and communication.

Transparency in Artifacts

Scrum has a number of artifacts that serve as the information radiators for all stages in the Scrum. The information is made clearly visible and understood to the team so the project progress trends are known. The availability and clarity of information is very significant in order to make smart decisions.

Product Backlog

The Product Backlog is an ordered list of requirements prioritized on the basis of their precedence and significance by the Product Owner, as well as the team. All the best-known features, attributes, fixes, and enhancements are documented in the product Backlog to make it clear and well-understood to the team.

Sprint Backlog

The Sprint Backlog is developed after the Sprint Planning Meeting has been conducted and Product Backlog is finalized. It contains user stories required to develop a complete increment of the product. Usually, some of the Product Backlog items are decomposed into the tasks or user stories agreed upon by the team to work on.

Burn-down Charts — Development Status

Use burndown charts to be honest about how the team is performing in a given Sprint. A burndown chart tells the true story of how the team is performing. Burn-down charts depict the amount of effort remaining in the future in order to complete the Sprint.

Scrum Task Board

The Scrum Boards are also used to reflect three things while working on a Sprint:

  • What to do?
  • What is in progress?
  • What is done?

Definition of Done

Transparency is also strongly related to the Definition of Done. Formally defining the meaning of ‘done’ reduces variability and the likelihood of undone work and measuring progress unambiguously (‘done’ or ‘not done’) increases transparency.

Having an imperfect Definition of Done implies there is Undone Work in your system. This Undone Work also causes a lack of transparency. Risks are hidden in it. For example, if performance testing is left Undone then it delays the risk of a non-performing system until close to release — when it hurts most.

Conclusion

Scrum is based on transparency depicted through its events and artifacts, but it cannot be achieved if there is a lack of transparency and communication in the team. It is difficult to establish and maintain full transparency if the members are hesitant or have fear of sharing their mistakes. In fact, everyone in the team need to show comprehension and respect to each other. Product owner and Scrum Master should motivate and encourage the teams to share any risks or problems they face in their work. While teams need not only focus on their individual achievements, they must also strive for achieving of the shared project goals. All these feedback and sharing are important to establish and maintain complete transparency of information flow, which enable the continuous improvement of the organization and the team.

Leave a Reply

Alamat email Anda tidak akan dipublikasikan.