Transparency towards stakeholders - how far? - Sharing of experience please?

I was wondering what was the limit of transparency towards the stakeholders that I should take into account.

There's nothing more transparent to stakeholders than having Done finished increments of work, which they can put to immediate use, and from which value can then be gained.

You haven't mentioned that once. Why not? Never mind delimiting what you're sharing in a document. That's just a promissory note. What about transparency over the increment, and over the empirical evidence of progress?

I agree with @Ian that the delivery of an usable increment of value is the best form of transparency.  Providing the empirical evidence that the Scrum Team is consistently delivering the value that the stakeholders can and want to use tells more than any "velocity chart" could ever do.  Anything related to that effort should be shared openly shared with stakeholders. 

But why would you limit transparency at all? The more the stakeholders know about what the Developers are doing to build the next valuable increment, the better they will understand the future efforts that will be needed. 

I have never intentionally restricted any information from a stakeholder.  

I would recommend thinking more about things other than transparency. Transparency is important, but unorganized and unfettered transparency isn't valuable to the team or stakeholders.

I'd start by thinking about who the stakeholders are and what information each stakeholder group needs. Not all information is relevant to all stakeholders. Some information is only useful to the members of the Scrum Team, while other information is useful to external stakeholders.

Since you mention internal communication, I'd also consider trust and building a safe environment. Depending on what is included in "internal communication", you could be building an environment where people don't communicate information because they don't want it shared outside of the team. Oversharing and being overly transparent could harm the team.

Part of a Scrum Master's accountabilities are to the broader organization and stakeholders to help them understand product development in a complex environment, empirical product management, and the Scrum framework. That includes how the events and artifacts work to give a high degree of visibility into the work that the team is doing. When these events and artifacts are insufficient, it's a combination of understanding the problem and then working with the stakeholders and the team to give the right amount and kind of visibility and transparency into the work.

Consider how putting information into a document may impact Transparency. Transparency now relies on the author(s) and what they enter into the document, which may or may not be accurate. 

Artifacts and Commitments should be the source of truth for the Product and there should be no need to delimit anything with them. Sprint Review is the Event where we provide and gain additional Transparency about the work, challenges and changes.

What is transparency like for your 3 Artifacts and Commitments? Do Stakeholders have access to them and understand what they see? 

Each should provide key information for Stakeholders and the Scrum Team...

- The current state of the Product Backlog and progress being made towards the Product Goal provides information about the long-term objective

- Sprint Backlog and progress being made towards the Sprint Goal provides information about the current Sprint

- Done Increments of Product provides value to users and customers and the Definition of Done provides information about the quality measures that need to be met to be part of an Increment

I totally agree with @Ian that the conveyance of a usable augmentation of significant worth is the best type of straightforwardness. Giving the experimental proof that the Scrum Group is reliably conveying the worth that the partners would be able and need to utilize tells more than any "speed outline" might at any point do. Anything connected with that work ought to be shared transparently imparted to partners.

@all !



Thanks a lot!

I had not received any notifications informing me that there were answers *, hence that delay of 2 months before I thanked you! 

* I guess there aren't at all...

@Ryan Kent, please, what do you mean by "Artifacts & Commitments"? 



I know the Scrum artifacts (the increment, the Sprint Backlog and the Product Backlog), but what about those "Commitments"? 



Thanks! 

@Ryan,

Please, forget my question! I got the answer by reading an article in the blog (would have liked to remove my question, but it seems I can't...).

Weird that I did not remember that concept of Commitments... Shame... :/