Tickets and User Stories for Scrum Ceremony Prep?

Why stop there? How about creating tickets to account for the creation of tickets :)

Product backlog items (“tickets”) represent improvements for the product. Items with potential value. Scrum Events are part of the framework that supports us in developing those improvement items into usable increments of value. We know that each Sprint we will be doing each Event so we don’t need backlog items or capacity accommodations for that.

Sprint Review is intended to be an opportunity to inspect the outcome of the Sprint and work out, with Stakeholders, any adaptations to the backlog that may be needed as a result of what is learned during review. This can be as simple as a conversation and showing and discussing done increment. All of the prep you are describing is not prescribed or suggested by the Scrum Guide. How might the team lean this out to reduce the prep effort?

I'd suggest putting the idea of a ceremonial demo to one side. The time spent is less important than doing the right thing.  Instead, consider having a Sprint Review event in which the Product Backlog is updated, in collaboration with invited stakeholders, at the last responsible moment.

I would recommend rethinking the idea of "demo preparation". Why does the team have to do any additional work to prepare for a demonstration? If the Product Backlog Items are expressed in a way that clearly communicates the state of the product after they are done and the team's Definition of Done is adequate, the team should be able to put an Increment somewhere for stakeholders to examine and give feedback.

Instead of the team giving demos, focus on what Sprint Review is supposed to be about: looking at past progress (the previous Sprint Goal) and the current Product Goal, discussing how the Product Goal could evolve, and how future Sprint Goals could support it. It's also useful to ensure a shared understanding of the context in which the key stakeholders in the product are working and how this environment may impact future decisions. None of this requires a demonstration.

In addition to the other great feedback, I encourage my teams to remove slide decks whenever possible and share working software. Some teams even bring laptops, tablets, and mobile devices and put them in the hands of stakeholders. This approach is much more transparent than slides and screenshots and enriches the conversations.

Regarding your question about time spent preparing for the Sprint Review, it is usually a 5-minute conversation the day before about who's sharing, what's being shared, equipment needed, etc.

Do you create tickets in your Product or Sprint Backlogs to prepare for Sprint Planning, Sprint Retrospectives, or the Daily Scrum?  If not, then be prepared for those to follow if you start putting tickets in for a Sprint Demonstration.  By the way, there is no reference in the Scrum Guide to a Sprint Demonstration.  There is a Sprint Review but the way it is described in the Scrum Guide is nothing like what you are describing. 

Almost every team that I have been involved with in some role described in the Scrum Guide has taken about 5 minutes to prepare for the Sprint Review.  Since the work has just been completed, it is usually pretty easy for the Developers to discuss the work that was done.  They can show the work to the stakeholders and even give the stakeholders access to the work for their own review.  The work that was planned for the Sprint was transparent to all of the stakeholders from the beginning of the Sprint and a lot of them were involved in discussions as the work progressed.  

@Thomas gives good advice about focus for the Sprint Review.  Slide decks are usually looked at one time and then forgotten.  However the Product Backlog and the Product are continuously reviewed and that is the focus for the Sprint Review.  @Chris' suggestion of avoiding slide decks entirely is one that I share.  If the work that was done can't be discussed in a productive manner without the requirement of a slide deck, then there is a bigger transparency problem that needs to be discussed and addressed. 

there is no separate prep needed if the Definition of Done is respected for all the increments. Team needs to retrospect and adapt the DoD if required.

It does not make sense to add task for demo preparation in your sprint backlog as mentioned by all the others here. I sense the thought itself comes from the fact that you are trying to justify the effort to someone for some reason. Focus should be on getting feedback from the demo. 

For the ceremonies themselves we deduct about 10% capacity during sprint planning. This is specifically about demo prep time.

Why only sprint planning is considered for deducting capacity? Why not other ceremonies as some time is spent there as well? 

Thanks for all your input. I've read through and I think I should clarify a bit:

This is the sprint review I'm talking about. It's just called demo by the business so we adopted that.

It's a joint demo from 3 related agile teams, working on different aspects and parts of the same website: features and enhancements, live service support, backend and cloud related changes. (the business did not want to have 3 different reviews (demos).

Some of these are pretty technical and has to be translated for the business with diagrams and models, also some involve UX changes, thus one of the reasons for slide deck. 

The business stakeholders are half tech and half business, and yes we also share screens and code for the tech stakeholders.

Someone mentioned something about transparency: Thats a bit right, there is a slight issue there. The business wants the outputs and outcomes for each sprint documented. Thats the 2nd reason for the deck, and it's a pretty big event.

The deck is pretty big with almost each developer (15), some of the QA, the delivery lead, scrum master and the PM having at least one slide. It does take a bit of time to prep, decide on what and who to demo, and to coordinate the presentation. 

If you are the Scrum Master for one or more of these teams, you have some work waiting on you to help the business understand the Scrum framework.  You are working in an organization that does not want to give up some old style project management practices.  The fact that they want to continue to call it a demo and that the slide deck is a requirement illustrates that in my opinion.  Both of those practices are mechanisms used to track projects to a deliverable as done in waterfall and "Project Management Offices".  In any kind of organization that claims to use agile practices and especially one that claims to use the Scrum framework, progress is seen by value being delivered to stakeholders that are actively involved in the work being done. 

"The business wants the outputs and outcomes for each sprint documented." They are documented in the items that are completed in the Sprint Backlog, the history of updates made to the Product Backlog based upon discussions undertaken with the stakeholders, and the updates made to the product. 

In my opinion, your organization does not nor do they really want to use the Scrum framework.  They may use some terminology from the Scrum Guide but they are not following the Guide in how to use and get value from the Scrum framework. 

I suppose you're right. Thanks for this Daniel

The deck is pretty big with almost each developer (15), some of the QA, the delivery lead, scrum master and the PM having at least one slide. It does take a bit of time to prep, decide on what and who to demo, and to coordinate the presentation.

Not sure what is the need to classify slides by roles if it is the combined work that delivers value. Why not have a simple deck with topics Sprint goals(status), Sprint metrics, Challenges and learnings, Demo (mention the features /stories which will be demonstrated also ensure the feedback is documented for it to be discussed in the retrospective), and Road ahead (highlight the stories you will pick for the next sprint and mention it is subject to planning and also take a feedback on the direction we would be taking). It may not be possible to completely do away with the slide deck, but I would suggest keeping it short and the focus should be on inspecting the increment and taking feedback.