Content of product backlog

The product backlog should contain everything related to one product (stories, bugs, tasks, non functional items, etc). Regardless of how many teams work on that product, or how many people are involved, as long as it's related to one particular product, they'll all be put on the backlog.

With this in mind, you may want to have a limited number of people (PO, DT, SM) with permissions to "write" on the backlog, with all others with a "view" only. note the PO would be the only one responsible, and they would order the backlog as they see fit.  

Should the PB contain purely items which are functional requirements/enhancements to the product which the DEV team disaggregate into tasks at each sprint plannning session according to the agreed DoD OR should the PB include tasks required, examples could be collation of requirements, sign-off from security colleagues, UAT from product testers outside of the DEV team etc etc?

Why would the sign-off and UAT activities you describe not form part of the Definition of Done and be completed by people wholly within the Development Team?

Hi Ian, by way of further explanation we build products for internal users within our organisation and that organisation is built in silos. We have to go outside our DEV team to secure skills we do not have - co-opting into our DEV team isn't yet within the company's thinking. 

With respect to the answers given by Ian and Eugene, I am confused as to whether tasks, external approvals etc are PBIs (my interpretation of Eugene's post) or quality thresholds within the Definition of Done, which is my interpretation of Ian's.

Further views welcome.   

I have my opinion but it has served me well for a long time.  Anyone can feel free to disagree. I would welcome the discussion.

I feel that the PB should only contain the problem or feature statements. (Keep reading for my description on why the items exist) They should be free from technical details unless that detail is absolutely necessary for acceptance.  I don't completely adhere to the "user story" format but I do agree that each item should clearly define the reason you are doing the work, the people/application that will be using the solution and how you know the solution is acceptable.  I go as far as to say that bugs are really nothing more than a story that describes some form of technical debt and that all of the parts of my story still apply. 

Tasks have no place in the PB because that is the work to be done while satisfying the story.  Tasks are introduced at the Sprint Backlog.  This statement from the Scrum Guide is what I use to support this. 

The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. 

There is nothing in the description of the PB that indicates that level of detail exist for PBIs. 

Every PBI should have direct connection to something that is needed in order to make the product better serve user or corporate needs.  I also say that if something is in the PB and later determined to be no longer needed or improperly stated due to new information, that PBI should be deleted not rejected.  There is really nothing written in that current PBI that would be relevant if the item should need to be revisited because it was written based on information known then and not information known now. 

The DoD is applied to every item in the PB to determine completion in addition to any acceptance criteria specifically stated in the DoD.  My rule is that if something applies only to the single story in the teams focus during refinement, then it should be contained in the story as acceptance criteria.  The DoD should contain anything that is applied to every story. If there are corporate requirements for "done" I suggest having a corporate DoD containing those items so that they apply to all teams.  Each team can have their own DoD as long as it is more rigid than the corporate DoD or contain only items that the individual team agrees to. 

So as concisely as I can summarise;

• PBIs should be limited to features & functionality
• Tasks may appear in the sprint backlog as work to be completed or in the DoD as a measure of completeness

Fair summary?

For the second point, it might be better to say that tasks appear in the sprint backlog as work to be completed and in the DoD as a measure of completeness.

How though do you intend to put transparency over the matter of the team being unable to complete the work so described?