Artifact transparency.
So this is something specifically brought in in the July 2013 scrum guide Ken and Jeff brought this
in because what they mean by transparency is that the product backlog the Sprint lock and the increment
are as we said before really key in terms of conveying information about the project.
The backlog is going to show the priority of what to be done and it's going to also show how much work
is left to do.
It also is going to show what is in the remaining list of things to do.
That the product Ohno's expecting the team to be working on immanently the Sprint backlog is going to
show what the plan is for the current sprint and the increment is going to show what has been done.
So in terms of these three items they convey a lot of information about the project and transparency
about the project being really open and about being really honest and making sure that what is conveyed
by each of these is open to all of the stakeholders and the whole scrum team.
This is really important to get all of these things right and to get the transparency on this to everyone.
So this whole section of artifact transparency has been added into the July 2013 scum guide to really
draw attention to the fact that and I've highlighted part of it that says scrum Mosse the development
team and other involved parties need to understand that the artifacts are completely transparent but
for the scrum masters role as far as this artifact transparency section it's to really make sure that
these artifacts are transparent.
That's the scrum just as wrong.
And the scrum master must actually help everyone to apply any practices in the absence of that.
So for example with the teams I work with the burn down is always visible the burn down is visible on
the floor that we work on so that everyone can see where we are everyone can see in terms of the Sprint
that we are on track or converse the that we are not on track.
So that sends a really strong clear message if we're not on track that something needs to be done and
no one can get around that in a scrum team nobody wants to get around that because we really want to
know the status of the project if we are on track.
It sends a boost to the team that we're doing really well and if we're not on track sends a message
to the team that we need to bring ourselves back on track.
Incidentally just to backtrack slightly the two things that I really should have drawn attention to
things that are tricky in the exam are that the development team can track their progress during the
Sprint monitoring the Sprint progress using Sprint burn down especially at the daily scrum meeting improves
the likelihood for achieving a spring goal.
The development team should be watching the Sprint progress themselves and keeping track of that making
sure that they are on track and that the day scrum they should be visible along with the Sprint Balac.
Another point is that the product owner compares the amount of work with that remaining so the owner
here is more on the hook for monitoring the progress of the release.
The team should be focused on the Sprint and the owner is seeing the bigger picture here.
So I just wanted to make that clear.