Tasks related to rollout of Product - some of which would be assigned to PO. Where does it go?

There will be various activities related to this including training etc

Is this work necessary to meet the Definition of Done and to create a usable increment of release quality?

@Ian, can you give any examples of PO activities that would be necessary to meet the Definition of Done and create a usable increment of release quality?

@Leo, I don't consider these kind of activities to be part of the "Product Backlog." That said, I don't take exception to POs and Scrum Masters in my company entering personal ToDo list items of theirs into the JIRA backlog corresponding to their project. In fact, I can see how it promotes transparency. However, if they take this approach, I suggest that they classify/label the particular items in a way such that they can be easily filtered out to leave a view of the true "Product Backlog." I'm interested to hear what others here think of this 

@Ian, can you give any examples of PO activities that would be necessary to meet the Definition of Done and create a usable increment of release quality?

By definition, these would be Development Team activities, although they might be performed by a Product Owner if he or she was also a Development Team member. Examples might possibly include:

- User testing and/or the evaluation of WIP, should this involve stakeholders to which only the PO has access

- Proof-reading of product documentation

- Product internationalization

- Making arrangements for the journey into service including long-term product support

If such things are required for an increment to be "Done", then whoever does the associated work (development) would be a Development Team member.

@Ian is right on track.  The Product Backlog is for the Scrum Team to organize the work that they need to do in order to deliver the product.  All work done to accomplish satisfying the Product Backlog Items (PBIs) should be done by the Development Team.  If there is work that only the PO or Scrum Master can accomplish that is included in the Definition of Done, then the PO or Scrum Master should be considered Development Team Members.  But, at least in my opinion, that is usually an exception rather than a rule because it can lead to conflicts of interest.

If the PO or Development Team are the individuals at your company that have to coordinate all of those activities and you want to have a way to track them, you might look at using a Kanban board or something else that you can include non-Dev Team members into to provide transparency.  But I would not suggest putting it into the Product Backlog that the team uses to develop solutions. At my current company, we have the similar situation where the PO is responsible for all the internal applications being rolled out and put into use.  But all the activities that involve outside individuals (training, setup) are not included in our sprints.  That is all done completely separately. 

@Ian, thanks for the reply. I agree with you generally. I'm hoping you can clarify one thing for me. It seems implicit in the scrum guide that the PO is the one that "accepts" the work of the team executed each sprint. That also implies some level of review and/or acceptance testing by the PO (along the lines of your first bullet), does it not? Does that mean the PO is wearing the hat of a dev team member then? I didn't have that impression.

@Daniel, thanks for your input. May I ask why you suggest the board be a Kanban board? Do you expect such a board to be WIP limited? Do you think this ought to include all other activities among team members that do not directly constitute changes to the product? 

The Product Owner’s acceptance of an increment may involve the review of completed work and the facilitation of a release decision. It should not involve any testing, as this would invest further value into the increment and would thus constitute development. Acceptance may occur during a Sprint Review for example.

I suggest Kanban because it is built on current workflow.  From what you have said, this workflow is larger than just the development org.  By visualizing the complete workflow for delivery, you are able to easier track and improve the process of moving items through.  Yes, it will involve WIP limits but more importantly it involves what I call "lane governance rules".  Not exactly sure what Kanban calls it.  But these rules make it very clear what has to happen in order for an item to move from one column to another.  It is similar to Scrum's Definition of Done but in Kanban there is a definition for each transition in state (i.e. each column). This helps with the transparency across the entire organization.