Less conventional PBIs in a Product Backlog

Do those "less conventional" PBIs truly represent negotiable scope, or do they represent quality criteria which are necessary for an increment to be considered Done and usable?

Scrum is a framework for solving complex problems not just for software products. Imagine a research team and what their PBIs might be or a marketing team or any number of different domains. 

 

If it works for your team and brings transparency to your work, why not?

This can be a dangerous thing.  I worked where a team decided to do exactly what you said.  It did not take long before the Product Backlog had more of the "less conventional" than actual items to improve the Product.  They started putting in items to do code reviews, to attend company wide meetings, to update the operating systems on their PCs and many others.  They wanted to make sure that everything they did was represented so that they all looked "fully loaded".  

The Product and Sprint Backlogs are not supposed to be to-do lists.  They are to represent the work that needs to be done TO A PRODUCT.  Things like deployment items should be part of the process of deploying, not listed in the backlog.  If it has to be listed anywhere I would recommend that the Definition of Done is a better place for it. 

@Ryan has a very good point.  Scrum is not just for software development.  So depending on the Product and the means necessary to produce the product, the items in the backlogs will be different.  But no matter what kind of mechanisms are being used to produce the product, I do not see how reminders, milestones, etc would be part of a product backlog. 

There are a few things to separate here.

The Product Backlog is a well-defined artifact of the Scrum framework. The Scrum framework, as described in the Scrum Guide, is "immutable" and making fundamental changes to what is described in the Scrum Guide would result in something that is not Scrum. That doesn't necessarily mean that the proposed process is bad, just that you should no longer use the term "Scrum" to describe it - the resultant way of working could be very good for the team and organization.

If you do want to stay within the Scrum framework, then you cannot add work that does not improve the product to the Product Backlog. That doesn't mean that the team shouldn't find ways to track and visualize their progress toward these milestones. Depending on your choice of tooling, they could very well be managed within the same tool as your Product Backlog, but it doesn't make these items part of your Product Backlog. Others may not make sense to manage as units of work.

Looking at your specific examples, I see cases of both.

System integration activities would be better served as part of the team's Definition of Done. The ideal state would be for every Product Backlog Item to be fully integrated before the team considers it done. If that's not possible in the current state, considering performing integration testing of all work done at the Sprint prior to the Sprint Review would be the next step.

I've found it helpful to maintain an improvement backlog of things that come out of Sprint Reviews, Sprint Retrospectives, incident analysis or root cause analysis, or suggestions from members of the Scrum Team. Improvements can be visualized, ordered, and selected based on who needs to participate in their resolution. The Scrum Guide suggests that these items could be placed into the Sprint Backlog without existing in the Product Backlog to help the team plan and execute their Sprint.

Activities related to release and deployment should be scripted. You may want to put work on the Product Backlog and/or however you track improvements to your way of working (perhaps the improvement backlog I mentioned), depending on the nature of the work. This will allow you to consider the work at Sprint Planning time and make sure the team is experimenting with improvements Sprint-over-Sprint.

There are several ways to visualize milestones, based on work. For example, when performing Story Mapping, a horizontal line is often drawn to show work that is essential to enable the minimal flow through the story from alternative paths that may be wanted in the future. Depending on your tools, you can find ways to associate units of work with different milestones, visualize how much work remains within each milestone, and change which units of work are associated with the milestone. The milestones themselves are not units of work, however, and it doesn't make much sense to put them on a backlog in many cases. However, there are cases where a milestone is an abstraction over several units of work and could be visualized through a workflow of its own.

Some good points above though I don’t think we should stop short and only reference the first line under Product Backlog definition. Following that line includes this one: “the single source of work undertaken by the Scrum team”

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

To Daniel’s point we don’t want a needlessly cluttered backlog as it can impact transparency if there is too much noise. Milestones may be better suited as Product Goals and reminders as DoD elements as examples. 

I still advocate for less prescription on what a PBI ought to be or not be. If it is work undertaken by the Scrum Team and it supports better Transparency for that team, it seems aligned to purpose to me.

If you are using Jira, milestones can be tracked by creating Epics and linking the items in the Product Backlog to the Epic.  I'm pretty sure that other applications have the same concepts.

I am not completely against this idea.  @Ryan makes a good point about the "single source of work".  But it is the single source of work that is needed to improve the product.  If you are sticking to that rule, I don't see any problems with what you suggest.  However, I would say that some of the things you mentioned could be considered impediments and should be addressed appropriately.  Take for example your release related items.  As @Thomas points out, it might be possible to automate so that they no longer are a manual item to track.  In my opinion, Items in the Product Backlog to automate this would be a better solution than repeating items to do the work manually.  Implementing automation would improve the product where just repeatedly entering items to do something manually is not an improvement. 

Thank you very much all for your answers, I am glad to starting having a new better view on this topic.

I'll now make a concrete example to better explain my remaining personal doubts (which probably have been somehow already addressed above).

Let's now imagine that we currently have a weaker Definition of Done which lacks of "update the documentation"/"deploy to production and make a sanity check"/"action X from Retrospective". Based on how I understood what you said above, those could be in a separate backlog/list. At Sprint Planning, we should take work from the two different "backlogs" and all size/estimate them to make a forecast (it is still work): IMPO, that would mean that we would not have a single source of truth any more and (again, IMPO) that would not be aligned with "The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint."

What I would like to also point out is that, IMPO, having two different backlogs (or additional to-do lists) would decrease transparency and possibly establish a hierarchy between the two, whereas I personally value the team continuous improvement as much as the product they deliver (as the first directly impact the second).

What do you think about that?

Let's now imagine that we currently have a weaker Definition of Done which lacks of "update the documentation"/"deploy to production and make a sanity check"/"action X from Retrospective". Based on how I understood what you said above, those could be in a separate backlog/list. 

Why would the Developers even consider such an arrangement? They are accountable for quality. Why would they allow quality concerns to be negotiated away?

Let's now imagine that we currently have a weaker Definition of Done which lacks of "update the documentation"/"deploy to production and make a sanity check"/"action X from Retrospective".

Why would you want to create a separate backlog for these instead of improving the Definition of Done to account for them?  That would be less wasteful in my opinion. 

If you have a weak Definition of Done, the best course of action is to strengthen the Definition of Done so that when a team says a Product Backlog Item is Done, it is truly Done.

Some things - like deployment or carrying out retrospective improvements - may not be good for the Definition of Done. Putting these into the Sprint Backlog so you can consider them at Sprint Planning and make work toward completing them visible to stakeholders is good. If or how you size/estimate the work or how you order the work will depend on what is helpful to the team - you may or may not treat them the same way as work in the Product Backlog.

I don't necessarily think that having two different backlogs would decrease transparency. You may have decreased transparency depending on how you implement those backlogs. I would highly recommend that teams use electronic tooling for their backlog. One of the things that electronic tools offer is the ability to search and filter. All of your work is in the same place, but your Product Backlog becomes a filtered view over all the work that only includes things that are improvements to the product and your external stakeholders are most interested in this view. However, other stakeholder groups may be interested in other filterings of the work, including combinations of filters. The team can have a view of all the work and consider ordering and dependencies while still making the right information visible and understandable to the stakeholders.

Thank you Ian and Daniel for your answers.

I agree with you that a "weak" DoD is supposed to be incrementally improved/enhanced. However, that is not just an activity which we can impose as Scrum Master (we have to make everyone aware of the importance/benefit), and which could take some time.

Moreover, team dynamics/process improvement or even documentation do not have to necessarily be in the domain of "quality".

My last question on this topic was more "How should we act, in this sense, until the DoD will be improved?".

Of course, it is a minor/philosophical topic, while the important thing is to deliver and usable and valuable increment at the end of each Sprint :)

My last question on this topic was more "How should we act, in this sense, until the DoD will be improved?".

That question is best answered by your Scrum Team because they are the ones that will be doing the work and the ones responsible for improving the Definition of Done.  

A technique I really like, and I think it came from PST Daria Bagina, was using a Now, Next, Future approach for Definition of Done.

This approach can help teams recognize that DoD emerges and evolves with the product.

You can identify all DoD elements that apply for today. You can also talk about the DoD elements you are getting closer to incorporating. And you can look ahead at aspirational elements you may want for your product in the future.

You can review DoD as part of Retrospectives to align it to your product evolution.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.