Who manages client communications for releases on Scrum team?

Question

I’m a Scrum Master on a relatively new scrum team. Management is wanting Scrum Masters to handle all client communications surrounding the actual release process: compiling the list of issues at the end of the sprint to send to the client for validation (along with client friendly summaries and screenshots), updating user stories with client notes, getting sign off on the list of features / fixes going up, etc. I’ve yet to find anything that supports the notion that this should be done by the SM. Should this not fall to the Product Owner? If I’m missing something, please set me straight.

Thanks

Answer 1

By the book is as @Daniel mentioned, the team decides who will own this responsibility.

However there are other variables that could help on defining this, for example, who's your client (marketing area, app user, other internal areas of the company)? Is your client aware of release communications?
If the client is prepared and used to the process (and the process is mature) anyone in the team that has communication skills can be defined responsible for this need.

In general the Product Owner could be the one to communicate, as he (should) know everything about the product release he could give the best approaches on explaining what came new on the product for any client: the ones not used to receive such information, or the ones that are experts in the product and will request more details about it. But this is not a rule.

Answer 2

The Scrum Guide is intentionally sparse on detailed responsibilities. There are some delineations that are important for Scrum to work properly and it calls those out - all others it leaves up to the team.

The things you mentioned are not things that are expressly called out, so I would say it's up to the team to decide who will do the work. There are two things worth calling out though.

1) While the Scrum Guide says anyone can do the work of managing the backlog and setting expectations to stakeholders, the Product Owner is ultimately accountable for it. I've seen too many teams who delegate this responsibility down from the Product Owner and they lose touch with it completely.

2) The one thing I see in your description that the Scrum Guide does have clear guidance on is the point about your management telling you who should do it. It says:

Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

These are definitely team decisions in Scrum.

Answer 3

Stakeholder Management is Mostly the Product Owner

The Scrum Guide is largely silent on issues of stakeholder management per se, although the Product Owner's role of managing the Product Backlog strongly implies that the Product Owner (PO) is primarily responsible for managing stakeholder requirements. Managing stakeholder expectations, on the other hand, is definitely spelled out as a PO responsibility, especially during the Sprint Review. In addition to working with the stakeholders to develop the Product Backlog, the Product Owner is responsible for:

• Inviting key stakeholders to the Sprint Review.
• Explaining what Product Backlog items are "Done" or "Not Done."
• Discussing the Product Backlog as it stands.
• Projecting likely target and delivery dates based on progress to date.

Of course, the Scrum Guide also says:

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

Contrariwise, while the Scrum Guide says that the Scrum Master is to help "employees and stakeholders understand and enact Scrum and empirical product development", the responsibility for stakeholder communications and management are not explicitly assigned to the Scrum Master role.

In practice, stakeholder management is usually a Product Owner responsibility, but there's nothing prohibiting a team from reallocating the work (as opposed to the accountabilities for each role). However, I'd consider a Product Owner that abdicates personal responsibility for stakeholder communication to be a framework implementation smell.

Your Process Lacks Adequate Customer Collaboration

The values and principles of the Agile Manifesto argue strongly against your current implementation. The Sprint Review is meant to be a collaborative exercise that includes the stakeholders, not a meeting that results in an indirect report to be forwarded to stakeholders. The Scrum Guide says:

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.

In addition, the Agile Manifesto and its principles include the following items:

• Customer collaboration over contract negotiation.
• Business people and developers must work together daily throughout the project.
• The most efficient and effective method of conveying information to...a development team is face-to-face conversation.

Client notes, post-Sprint validations and sign-offs, and "summaries and screenshots" instead of Sprint Demos are all giant red flags that your process is not adhering to either the Scrum framework, or to the agile values and principles. Your team, your organization, and your stakeholders should all carefully re-evaluate whether you really want to commit to an agile process based on real collaboration, or whether someone just wants to cloak a more traditional project framework with a few loosely-applied Scrum ceremonies.

Is it the substance that truly matters, or just the appearance? Based on your description I'd bet good money on the latter, but your mileage may vary.