End of sprint newsletter??

Is there a reason why the interested parties can't attend the Sprint Review? It seems like they would get their questions answered. Even if they can't attend the Sprint Review, would recording the Sprint Review and distributing that to them address their concerns? Both of these options appear to achieve the same thing but would be far less work for anyone.

Honestly, I'm a bit curious why upper management is interested in what tasks the team accomplished instead of what outcomes the team achieved (or will enable stakeholders to achieve with their changes to the product).

Thoughts on how to streamline this so it doesn't take me too much time?

If it's waste, why do it at all?

There could be value in this newsletter or a similar exercise. What information do "upper management" need, so they can demonstrate improved servant leadership, and make themselves more useful to the teams doing the work?

Organizational impediments and constraints that inhibit agile value delivery -- and which only senior leadership are in a position to remove -- might be a useful thing to communicate.

I second what @Ian Mitchell and @Thomas Owens have said.  This seems like an opportunity for you, as Scrum Master, to educate these managers on how the Scrum framework is used to deliver value and that measuring the value produced is more important than measuring tasks.  

Producing this kind of report is an indicator to me that they plan to compare teams based on how many tasks are done.  That is an anti-pattern for Scrum and agile in general.  

Does it sound as if this might be a status report disguised as a newsletter? The issue with a Sprint newsletter, status report, etc. is that there will most likely be a loss of transparency. As has been said, there's a Scrum event for this - the Sprint Review. A newsletter will be hard to replace a collaborative Sprint Review where working product is shared.

Thanks all for the comments.

@Ian Mitchell and @Thomas Owens 

From what I gather the end of sprint newsletter isn't intended to replace our end of sprint activities.  We do have a Sprint Review which we record and distribute.  Key stake holders will often attend the Sprint Review to get questions answered and track progress.  I think the intent of the newsletter is to showcase to other teams across our organization and upper management what we've accomplished as a team.  This provides almost a condensed version of our Sprint Review so others can quickly be stay informed about the things we've accomplished without having to watch the full Sprint Review which typically runs between 30 min to 1 hour.

@Daniel Wilhite

"Producing this kind of report is an indicator to me that they plan to compare teams based on how many tasks are done.  That is an anti-pattern for Scrum and agile in general."

This is a good question that I can follow up with my manager.  I need to better understand the motivation for the newsletter.  I think it's something he's seen other teams do which is why he is requesting it.  I've seen the other teams newsletters and its always enlightening to see what others are doing across the organization.  Especially how various teams approach solving different operational issues.  I could see benefit from the newsletter helping teams learn from each other as the motivation vs management comparing teams.

@Chris Belknap

Does it sound as if this might be a status report disguised as a newsletter?

I believe that the intention is not to have the newsletter be a status report.  Our team already has established processes for reporting project statuses.

I think the intent of the newsletter is to showcase to other teams across our organization and upper management what we've accomplished as a team.  

If that's the intent, I'd suggest that managers ought to be the ones who write it. They will need to create, communicate, and reinforce the case for agile change if your team is to serve as a useful exemplar to others. This is not something that can really be delegated.

Is "communicating with customers" not something people think delivery teams should be doing?

Yes, senior execs are your customer. Roast me, that's fine....but if you stop providing services to them, your team will go bakrupt very quickly (and that is the impact your customers have on your organisation).

OP if other teams already do this - tell your PO it needs to be a PBI - the PO can identify a priority and identify if your team is the best to conduct the work or if your team is best served by outsourcing this work. The PO can identify how far to deviate from existing product, be influenced by existing product, or blatantly rip off some other teams newsletter.

(Probably it would be bettter if there was an internal comms team doing a single newsletter for the organisation that picked up articles per product rather than a whole newsletter per product, if there is a real need for internal comms)

If the people receiving this "newsletter" are stakeholders in the work, then they should be attending the Sprint Review. If they aren't stakeholders, then I'd suggest that the development team shouldn't be the one to write it. Communication about what is going on in the business tends to be in the purview of management, so perhaps one of the people from upper management should be attending the Sprint Review and writing an appropriate summary of it based on the needs of the people who are receiving it.

In my opinion, this highlights the need to be able to radiate all of the necessary information that stakeholders may require, so that such End-Of-Sprint efforts like the proposed newsletter are no longer required.