User story to track/allocate time for Sprint Review?

What would be the benefit of adding a user story for a demo? What value does it give to the user, outside of the other user stories?

I would encourage you to find out the "why" behind this. If it's for "tracking time", the Scrum events don't need to be recorded on the board (in my opinion). If it's something else, I'd be curious.

I see the link mentioned that the correct answer is to create the user story. I haven't read much from the PMI but I wouldn't trust that as the answer (their justification seems odd as well).

I believe any user story that a development team works on should provide some business value. creating a story to track the time for scrum events does not add any business value.

I would recommend to use Build & Run strategy

- Build: 80% of the development team's available time, dedicated to achieve sprint goal (can be used to determine teams velocity)

- Run: 20% of the development team's available time for non development tasks (emails, meetings, prod-support, etc...)

The Scrum Guide distinguishes each Event, provides suggested time-boxes for each event and describes each artifact separately on purpose.  As I interpret it (others may differ) I see the Review and Retrospective as the last events to signify the end of work on a Sprint.  The Planning event is there to begin work on a Sprint.  The Sprint Backlog is the identified list of Product Backlog Items that will be worked on during the Sprint time-box.  Since my interpretation is that the Review and Retrospective is outside of the Sprint time-box, I do not see why you would add any a story to the Sprint Backlog as it is not work undertaken during the Sprint. Instead I suggest that the work to prepare for the Review would be activity undertaken for each story in the backlog and would be better identified as sub-tasks for each story. I ask if you would add stories into the Sprint Backlog to account for people updating their time sheets or attending meetings with HR for annual reviews?  That would be "work" done during the Sprint but has nothing to do with the work needed to accomplish the items pulled from the Product Backlog.

I read the information at the link you provided and I will be totally honest in my next statements.  I mean no offense to Mike Cohen as I respect and have put into practice a lot of what he has advocated.  However I do disagree with some of his interpretations and practices. This would be one.  But note that I said "interpretation" and "practices".  Since Scrum is a framework and does not define any practices, everyone is free to create whatever practices and process that works for your organization. As long as you are within the Scrum framework you can still call it Scrum. While I would not advocate this practice I can see how it still works within the framework.  I also see why PMI would include this in the PMBOK Guide as their certifications/practices are geared more towards old styles of project management for which every minute of an individuals work should be accounted.  Scrum isn't about managing projects as much as it is about consistently delivering value.  Agile was created as an alternative to old style project management.  So I fully expect that there will be differences in the philosophy and practices of practitioners of each style. 

@Daniel Wilhite, Even I was of the impression that the Sprint Review and Retro are outside the sprint time-box until I read this article by Ian 

https://www.scrum.org/resources/blog/typical-sprint-play-play

Also, the sprint is the container for all other events. I found this except from the Scrum guide...

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

However, in practice I do see many teams doing the retro and review outside the sprint time-box including the teams I work with. Sometimes the way the teams  are distributed forces this way of working especially due to time differences.

I still do not see a reason why a story needs to be in place to account for the demo. It seems like it is there so that people won't forget to demo it. Can't they just factor the amount of time it will take? Can't this be done during capacity planning by reducing the hours instead of a using a story?

Hi Steve,

Well a product backlog with its stories actually is there to be very transparent about the functionality ‘you think, you still need to deliver’ for your product. So it’s not a list of ‘tasks’ or ‘things’ you still need to do or need to ‘plan for’.

A product backlog is not a planning.. It’s a list of stories your product is still missing from. And yes you also do a bunch of things during a sprint which isn’t visible on your product backlog. I won’t go into detail there because we would wonder off.

But for this specific question, you are talking about a scrum ceremony which should be time-boxed, meaning that the time spend on these reoccurring events each sprint remains constant. So why not ignore them completely? They shouldn’t affect your velocity.

@Steve, Sorry to come back so late but unfortunately I missed you reply to me.  

I admit that my choice of words was not that great.  "..outside the Sprint time-box..."  really should have been "at the start and end of the Sprint time-box".  As I mentioned I see Planning as the start of a Sprint while Review and Retro finish it up. But I still do not believe that there should be stories in the backlog for them.  That still screams project management/time management to me. But if you do this, do you also include stories for refinement and would it show to be in progress for the entire Sprint since that is an ongoing activity?  As I've said many times, there is no right way to do it so I'm just curious how you handle it in your model. 

@Dan, my original post was based on the info I saw in that link though there is a similar practice my team follows which I do not encourage. Most recently, I had to get a manager involved to get that practice removed. It looks like the team  I work with responds to certain things better that way.

Seems I'm late to the party here

I am trying to understand if the practice of using an user story to allocate time to demo a product increment is correct?

I've never heard of such a practice as you describe it. If others in your team or outside of it (managers?) are requesting it, have they bothered to research what it's supposed to do?

I tried to reason from the perspective that the stakeholders are the users of the potentially releasable increment and therefore it may be correct, but somehow the practice seems rather odd to me (in my opinion). For ex: How would a team estimate such an user story? Isn't it already understood that we'd have some time reserved for a Sprint Review, therefore do we really need to allocate time through an user story?

Conversely, if stakeholders are not users of the potentially releasable increment, would it then be accurate to state the practice is incorrect? :)

It is always a good idea to be organized. How organized? - that depends on the team itself, taking into consideration the surrounding variables. If you're using Scrum, the demo already has time allocated to it (check the timebox), so why consider allocating time to the timebox? As far as estimation, what exactly would you need to estimate? The effort/complexityrequired to spend 0.5, 1, 1.25, 2, 3, 4 hours? :)