Should we put internal team tasks into Product Backlog?

Question

Developer Team always has internal tasks (such as environment improvements, process improvements and so on). Sometimes they can be related with current project, sometimes not.

There is no problem, if these tasks are related with current project (for example, make Continuous Integration process for current project). Product Owner will have no objections for adding these tasks to Project Backlog and can set priority for all of them.

But what should we do, if these tasks are common and not related with current project (For example, we want to establish code conventions and use automatic code style checker in our process). Even if we will persuade Product Owner to add this task to Product Backlog, I am sure, he will set priority for this task as small as possible. And it has sense for him, because accomplishment of this task will not give huge benefit for current project. But in other side, it will give quality increase for Developer Team in current and all other projects (PO, of course, absolutely don't care about other projects).

And in general, I think it's not a good idea to add to Product Backlog tasks that does not related directly to the product.

But if we will not inform Product Owner about these things and not add them to Product Backlog, but doing them during Scrum, then Scrum well lose his transparency (one of three Scrum pillars, as Scrum Guide said).

So, what should we do with this kind of tasks?

Answer 1

Short Summary

This is a complex topic, but the short answer is:

1. Team-defined tasks necessary to implement stories belong on the Sprint Backlog, not the Product Backlog.
2. Only the Product Owner may actually add items to the Product Backlog, although the team should certainly be free to submit stories to the PO for consideration and possible inclusion.
3. The Product Owner must prioritize non-feature stories that are still essential to team operations.
4. Great Product Owners always have a few "evergreen" stories that can be added (and re-added) to the Product Backlog when the situation warrants.

Housekeeping, Tech Debt, Operations, and Process Stories

The Product Backlog is a way for the Product Owner to make the cost of doing business visible to the organization. That means that some team-process stories must be placed on to the Product Backlog and properly prioritized in order for Scrum to function.

Consider the following examples:

1. As a new developer
   I need to configure my development environment
   so that I can work productively on Product Backlog items.

2. As a Development Team
   we need a Continuous Integration server installed and configured
   so that we can be sure that each Sprint delivers a potentially-shippable increment.

These stories belong on the Product Backlog. In fact, the first story should be added once to the top of the backlog for every new developer that joins the project since it's something that needs to happen, requires resource allocation from the project budget, and consumes team capacity until the new developer has a functional working environment.

Even though these types of stories don't add value to the product, they add value to the project. In addition, CodeGnome's Law of Transparency says "No invisible work, ever!" That means that these types of process stories must be visible because they represent work that has to be performed and will create drag on the project until they're properly implemented.

Some things, like installing a new IDE, might simply be considered process overhead. Drawing the distinction between process overhead that should be solely on the Sprint Backlog, and stories that affect the Sprint Goal and the capacity of the Sprint itself, requires each team to develop some practical definitions and filtering criteria.

There really isn't a "one size fits all" answer, but the distinction between overhead and capacity-consuming work certainly must be hammered out by the team. Once the distinction is made, then the proper process for each type of work should be followed consistently and with as much rigor as the team can manage.

Answer 2

The PO needs to be aware of these, and I would help facilitate a discussion between the devs and the POs so that he knows the pain and short/long term impact of not doing these. Trying to do things under the radar is a great way to have angry customers (including the PO) and the team should always strive to be transparent about issues they are having.

As for whether or not it should go into the backlog I would ask the team what they want to do. It's probably going to go 1 of 2 ways:

• Put them in the backlog and treat them like a normal story. Task it out, have the team demo it to show the value it's bringing to the team and the business.
• Keep them out of the backlog but plan for reduced capacity since the team is going to be working on it. This keeps the backlog clear of non-project work, but your velocity is probably going to take a hit since the team is not getting story point credit for work they are doing.

Answer 3

If the task for the developer is re-occuring like: "Fill you your timesheet so you get paid," thats overhead and doesn't go into a iteration backlog.

If the task or story provides a discrete, tangible value, whether functional or non-functional, it goes into the product backlog and eventually the iteration backlog once prioritized and committed to by the team.

Work with your product owner to get them to understand the value of non-functional tasks as they almost always impact either quality of the product or ability of the team to deliver a given volume of functional items in the future.

Usually when I hear dev's on my teams describe a backlog as non-functional I interpret that we are working with a "non-well-explained-enough to the PO for them to understand the value" backlog that requires some communication work.

Answer 4

Could we really refine the question as how do we report effective working time?

I absolutely agree with Code Gnomes -"No invisible work ever" but in the situation where you have an ongoing drain on resource time, potentially outside of the project for example

• Devs have a weekly round table. It lasts 1/2 day every week
• Seniors on the project have managerial responsibilities to direct reports taking them out 1 day a week.

I do not believe these should be on the backlog, but you should report on the effective working time of the resource being less than full time. I know in TFS you can show this, and if you keep a traditional project plan you obviously can but I don't know about any other tools out there.