Do stories/tasks for tools belong in the product backlog?

Are these tools one-time use or do they benefit the Developers long term?  I ask that because if the tool is created to allow the Developers to do their work more efficiently on a long term basis or to make the product easier to maintain and support. If so, then I see that as work that improves the product. 

There will always be work to do that isn't directly related to a customer but is required for a product to be successful. My opinion is that all of that work should be visible in the Product Backlog. But this is only my opinion and may not be the same as your Scrum Team's.  And in the end, it is what the Scrum Team thinks that matters. 

I would suggest that you look at the Scrum Guide's section that explains the Sprint Backlog.  It might be that some of these "tooling tickets" don't belong in the Product Backlog but would be better to place directly into the Sprint Backlog.

Are these improvements something the Product Owner can reasonably order on the Product Backlog, in relation to other work, so value will be maximized?

Perhaps they are more to do with improving product quality, which the Developers are accountable for.

In addition to the above responses, in as long as the PO can account for those tools as providing maximum value they would be added to the product backlog. The sprint goal is the focus and having developers tuned in without the encountering impediments would help deliver a product increment at the end of the sprint.

This depends on how you define value and benefit to the stakeholder. Building and maintaining tools very well could deliver value and benefit to the various stakeholders interested in the product. Some tools may allow the team to increase the quality of their work. Other tools could reduce the time it takes to perform tasks, especially often-repeated tasks. Improving product quality or reducing the time it takes to get work done seems like it could be valuable to stakeholders, even if it's not direct value delivered by the product itself.

Without more information about what these tools are or their intended impact, it's hard to say for sure. I don't think you can exclude putting at least some categories of tool development, maintenance, and/or configuration on the Product Backlog. However, there may be other categories of tool-related work that is more appropriate for the Definition of Done, acceptance criteria, or work items on the Sprint Backlog.

Are these tools one-time use or do they benefit the Developers long term?

They benefit the devs long term, like having a tool to deal with merge conflicts.

I would suggest that you look at the Scrum Guide's section that explains the Sprint Backlog.  It might be that some of these "tooling tickets" don't belong in the Product Backlog but would be better to place directly into the Sprint Backlog.

How does that work? Do we create the tickets during the sprint in the sprint backlog?

Perhaps they are more to do with improving product quality, which the Developers are accountable for.

I would say it's mostly workflow improvements, like easier merging and stuff like this. But there might be some tools that also pay into the quality part.

Are these improvements something the Product Owner can reasonably order on the Product Backlog, in relation to other work, so value will be maximized?

I guess? They are stories that the PO can order or what do you mean by that?

I don't think you can exclude putting at least some categories of tool development, maintenance, and/or configuration on the Product Backlog

Do you mean different categories in the backlog, like one section for the pure "product" backlog which will produce the valuable increments according to the definition of done and some other section like a tool backlog? Am I understanding this right? Wouldn't this be a breach of the part in the guide where it says the product backlog is the single source of work undertaken by the Scrum Team?

My understanding is that a Product Backlog can have PBIs which may not provide direct value to end-users/stakeholders but are required for the Product development.

Having such items in the Product Backlog gives the Product Owner a chance to order them appropriately.

So if an item adds value to the product, workflow or quality and is actually usable in the intended sense it belongs into the product backlog, right?

Which would mean that having a story to only design the tool is not an appropriate PBI because it's not usable. Is my understanding correct?

Would "Tool xy can be used" be an appropriate sprint goal or should the focus always be more on the product for the customer to ensure an iterative increment every sprint? The stakeholders probably won't show any interest in this, that's why I'm asking. If the tool is part of the increment because it fulfills the definition of done, I can show it in the review.

Lets say I'm developing an app and at the review I only show our new tool which lets us build the project with one click. Is this an increment you would show at all? Is this even a increment?

So if an item adds value to the product, workflow or quality and is actually usable in the intended sense it belongs into the product backlog, right?

I would agree with this. It is probably a broader stance on what "improve the product" means, but I do believe that improving the team's ability to deliver is a product improvement.

Which would mean that having a story to only design the tool is not an appropriate PBI because it's not usable. Is my understanding correct?

I prefer the Product Backlog Items represent the delivery of value. Having a design for a tool doesn't deliver value for anyone. For example, the team cannot use a design to improve the product, the quality of the product, or their workflow. They need a usable, configured tool to do so.

Would "Tool xy can be used" be an appropriate sprint goal or should the focus always be more on the product for the customer to ensure an iterative increment every sprint? The stakeholders probably won't show any interest in this, that's why I'm asking. If the tool is part of the increment because it fulfills the definition of done, I can show it in the review.

Lets say I'm developing an app and at the review I only show our new tool which lets us build the project with one click. Is this an increment you would show at all? Is this even a increment?

I see two sides here.

The Sprint Goal should be the primary objective of the Sprint. In most, perhaps even nearly all, cases, the Sprint Goal should focus on delivering value to the external stakeholder. In addition, I tend to focus on what the outcome is and not the output. A usable tool is an output. An outcome could be something like "the team's time to resolve merge conflicts is reduced by 30%". There could be new tools, modifications to existing tools, or workflow/process changes that enable the team to do this. I'd still be a little hesitant to have an internally-facing Sprint Goal like this, but I don't think it would be inappropriate. I would still want to see product improvements delivered to customers and end users, even if they aren't explicitly tied to the goal itself.

However, the Sprint Review isn't a demonstration. You don't need to show your tools in the Sprint Review. You should talk about the Sprint Goal, if you've achieved it or not, and what the impact of achieving that goal is for the various stakeholders. I like to look at the Sprint Review as a synchronization event, though. It's the only time where the whole Scrum Team and key stakeholders are together. It's a good opportunity to look at what is changing in each environment. What is the Scrum Team learning? How is the Scrum Team improving their ability to deliver stakeholder value? What has changed in the marketplace or in how the product is being used? These are more important things to talk about then demonstrating anything.

Do you mean different categories in the backlog, like one section for the pure "product" backlog which will produce the valuable increments according to the definition of done and some other section like a tool backlog?

No.  There is one Product Backlog that contains all items identified to improve the product.  Sometimes work on the infrastructure used to deliver the product improves it.  Your example of a merge tool is a good one.  It improves the team's ability to deliver the product updates on a consistent basis.  That is an improvement that helps the product. 

All items should be in a single backlog and they should not be segmented within.  The job of the Product Manager role is to ensure that the items are ordered in a way so that the Developers are working on the right things based upon stakeholder needs.  In the case of a merger tool, the stakeholders are the Scrum Team themselves.  In product development, just as in life, occasionally you have to put your needs above those of others.  

How does that work? Do we create the tickets during the sprint in the sprint backlog?

Yes.  The Scrum Guide states that the Sprint Backlog consists of the Sprint Goal, the set of Product Backlog Items selected for the Sprint, and an actionable plan for delivering the Increment.  In the teams I have worked with, the actionable plan often results in items being added directly to the Sprint Backlog.  This is the result of refinement, which the Scrum Guide calls an ongoing activity. 

So if an item adds value to the product, workflow or quality and is actually usable in the intended sense it belongs into the product backlog, right?

If an item adds value to the product it belongs in the Product Backlog.  Improved quality adds value to a Product.  Improving workflow needed to deliver the Product adds value.  Refactoring code to make it easier to manage and more performant adds value to the Product.  Not all value is directly related to the functionality the Product gives to the end user.  Consider how much people pay attention to the look of a car.  Or to the size of a phone's display.  Those are valuable to people. 

Which would mean that having a story to only design the tool is not an appropriate PBI because it's not usable. Is my understanding correct?

I don't think this is a case for a Product Backlog Item but I would not oppose an item in the Sprint Backlog for this purpose.  As I said before, this would be part of the plan to do the work needed to achieve the Sprint Goal. 

Purely rational you could say: "it''s work we're going to do while and for developing this product, so it should be in the Product Backlog". (or if you want the Sprint Backlog)



It's more transparent and you can then talk about this in the Sprint Review. If you only do these types of work for multiple Sprints, I expect the Stakeholders to question when you're going to finally do something they actually asked for. The team needs to find a good balance, and the Scrum Master and the Product Owner need to guide the Developers in this decision.