I suppose that Product Backlog is a place for product requirements (business scope), and not for tasks.

But some sources suggest that we also need to add tasks. For example, tasks that need to be done to make work possible (something like configuring development environment)

Should Product Backlog contain anything besides product requirements (business scope)?


The 2020 Scrum Guide says:

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.

Most of the thinking that I've seen has been that the work in the Product Backlog should be something that adds value to the customers and users of the product and that tasks should be assigned to the Product Backlog Items that would require them to be done.

There are differing opinions - some people (including myself) propose including the work in all of the items that it would be needed for to ensure that the items in the Product Backlog can be ordered independently while others propose including the work in one of the items and ensuring dependencies while others would suggest putting the work directly in the Product Backlog and managing dependencies that way.

I'd recommend working with the team to figure out what works best for the team as well as the stakeholders. Be sure to consider everyone who is looking at the Product Backlog to make sure the presentation of the backlog is helpful to them.


You asked about Scrum in other questions on this site, so I'll asume this is about Scrum. The scrum guide refers to the work sitting on the backlog as Product Backlog Items (PBIs), not product requirements or business scope. The work a team does for a product isn't just implementation of requirements. You can have bugs, you can have technical tasks, you can have spikes, refactoring or clearing up technical debt.

As Thomas Owens mentions in his answer, you can sometimes have tasks assigned to the PBI that would require them, say refactoring for example. However this is not always possible as it can be something that's needed by the entire product not just some PBIs, things like changing the architecture of the application for better scaling, or something.

You really need to think about what kind of task it is. Configuring a development environment maybe isn't really something that should sit in the backlog since it's not enhancing the product per se. Maybe it can sit in the Sprint backlog instead of the product backlog. Also, there are tasks and there are tasks. Tasks as division in smaller pieces of a PBI don't belong in the product backlog, only in the sprint backlog. Technical tasks like the changing of the architecture of the application example I just gave can be placed in the backlog as a PBI itself.

It really depends how the team organizes their work and interacts with others. I've worked on one project where we used technical tasks in the backlog and the CEO once asked "what the heck is that?" during a discussion at a review meeting. He found the explanation interesting, but things could have turned out another way. So figure it out with everyone how best to proceed, and if you are still in doubt, you can just experiment, inspect and adapt.


This is a decision for the team. Some Scrum teams differentiate Product Backlog items (outcomes) from Sprint Backlog items (tasks needed to deliver those outcomes during a sprint). In tools such as Jira you can add tasks directly under a backlog item and the tasks move along with the parent item. So much depends on the planning methods and tools preferred by the team.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.