Scrum Artefacts: Visibility Makes for Trust and Transparency

In a recent post, Scrum Team: The Importance of Trust and Transparency, I explained how important the two elements of trust and transparency are for effective collaboration.  In this follow up post we will look at how the visibility of Scrum Artefacts is essential for allowing, if not actually creating trust and transparency within a team. 

By its very nature, a Scrum Team is multidisciplinary.  A lot of information is gathered and shared by each individual member, which helps create a better understanding of their capacity and accountability.  It pushes the team to communicate better.  Feedback given by both team members and users on each user story (items to be developed) allows the identification of issues and constraints that can be addressed, improved or adjusted.  This is what is meant by an open and blameless culture; each member is accountable and confident of discussing issues honestly.  To achieve this, however, it is imperative that Scrum artefacts are made visible.

A lot of ifs…

The visibility of Scrum artefacts provides the necessary transparency for the team.  If these artefacts were not visible, then nobody would be certain of what other team members were working on.  If they don’t know what other members are working on, then it follows that they would be unaware of any issues that may have surfaced.  If issues and problems are not addressed, then the product cannot be adapted (and the last if …)  If the product is not suitably adapted, then risk and extra costs may arise. As well as this, trust amongst team members will be diminished.

The Scrum Master ensures that all artefacts are transparent by inspecting them, looking for patterns and noting the differences between the expected result and the actual result.  Visibility of progress and the trust, transparency and accountability of each team member makes for accurate inspection of the product increment.  This in turn allows for accurate decisions to be made which help control risk and increase value. 

Product Backlog

Everyone concerned with the development of the product must be able to see the Product Backlog in order to work collaboratively.  Stakeholders should have access to the Development Team but should not try to add work to the Sprint without the consent of the Product Owner.  This is because the latter solely owns the Product Backlog and it is from here that the team take and claim ownership of specific stories to be included in the Sprint.  The only one who should be adding to the Product Backlog is the Product Owner.  It is, however, acceptable for the Scrum Team to communicate any suggestions or items that may be missing.  Any additions or changes must be mutually agreed between both Product Owner and the Development Team. 

The Product Backlog is never complete as items are removed from it and added to the Sprint Backlog which is owned by the Development Team.  By having visible access to the Product Backlog, however, the Team understand the goals of the Sprint as well as their own role and responsibility during it.  This, in turn allows them to predict future tasks for the Sprint. 

User Stories

User stories are listed on the Product Backlog in order of priority and normally, the higher the priority the more clearly defined the task.  The language used for these stories is that of common jargon that is understood by everyone involved.  By this means issues are reduced and trust between team members is strengthened.  This is effective collaboration made possible by the visibility of the Product Backlog.

Sprint Backlog

The Sprint Backlog is a list of tasks that have been identified by the Team during the Sprint planning.  They are the user stories taken from the Product Backlog that are to be completed during the Sprint.    Each team member takes ownership of and assigns themselves to a specific user story so that everyone knows who is doing what in the Sprint.  By doing this, not only is the Team able to create a plan to meet the current Sprint but they can also see the progress being made.  The Sprint Backlog can be a physical board or an online tool, but it must be visible to all. 

The Scrum Board

All tasks taken from the Product Backlog are placed on the Sprint Backlog and then on the Scrum Board.  A physical Scrum Board makes work more visible so the team can hold each other accountable.  Each member discusses what they are working on and posts it on to the Board with their name or sometimes a photograph by the side of their task.  By this means accountability is established and feedback for the current Sprint is visible so that everyone can see who is working on what as well as the progress being made.  Again, visibility of the Scrum Board encourages trust and transparency between team members.

Sprint Review

The Sprint Review is carried out at the end of each Sprint and focuses on the inspection and adaptation of the product increment.  Considered to be a fundamental part of the Scrum process, the Sprint Review is where each team member speaks openly and honestly about both positive and negative aspects of the recently completed Sprint.  The objective of the review is to resolve any problems and difficulties that may have arisen and to propose ways in which they could be improved upon or avoided in the future.

Remember, Scrum methodology is based on empiricism, so problems and issues are not something to be disappointed by but rather learned from.  This is where the Sprint Review comes in.  Mistakes and errors are inevitable, but they can lead to better performance in the future providing trust and transparency amongst all team members exists.  If one team member is afraid to admit to a mistake, that is an issue because then the process fails to be transparent and the lack of admission can lead to a knock-on effect.  A mistake that is hidden rather than addressed can lead to more problems, whereas problems over which people have taken ownership can be brought out into the open to be discussed honestly.  They can then be dealt with because they have been made transparent. 

Transparency then, allows issues to be recognised, raised and resolved and this is the reason why Scrum methodology insists that the work of the team is visible to all concerned.  This can be demonstrated in the Sprint review.  These short working cycles almost generate a pattern of predictability over time, so that when new user stories occur from new necessity or new planned requirements, they just need to be added to the Product Backlog in order of priority.

Sprint Retrospective

As with the Sprint Review, the Sprint Retrospective is carried out once the Sprint has been completed.  The difference between the two is that whilst the Sprint Review focuses on inspection and adaptation of the product that the team were building, the Retrospective focuses on how the team built it.  It is not, however, a meeting used to record complaints, but is rather a time for the team to discuss and suggest effective solutions to problems that they experienced during the Sprint.  By this means they can develop action plans for the next Sprint. 

As I have said before in What makes a good Scrum Master – the do’s and don’ts of a Scrum Master’s Role, a good Scrum team continuously evolves and is always looking for ways to improve.  The Retrospective is the perfect time for this to happen.  It is a meeting that the Scrum Master facilitates and the Product Owner attends and is a time for the whole team to align itself.  As I explained earlier, the Sprint that has just ended is discussed in the Retrospective, so the environment for this meeting needs to be comfortable for all if ideas and suggestions for improvement for the next Sprint are to be aired.  Discussing how they worked on the project makes again for visibility, trust and transparency and ultimately effective collaboration between all team members.

So, I hope in this post I have been able to portray how important visibility is in terms of Scrum Artefacts and how it makes for trust and transparency within the Scrum team.