Improvement items in the Product Backlog

The Scrum Product Backlog is Product Owner’s tool to communicate customer’s needs to development Teams in a prioritized order. Unfortunately that is not so simple as it sounds: Backlog and the way it is implemented creates the boundaries of self-organization and defines the dynamics of the organization. In this post I will look into this from Teams’, PO’s and organization’s angle. In a later post we will take a look into more technical aspect.

The motivation for this post came from ScanAgile 2011 conference. Hannu Kokko in his presentation about Large Scale Continuous Integration (the best presentation in ScanAgile 2011 according to my colleagues) mentioned that in order to get CI implemented the improvement activities should be put into the Product Backlog. I think there are also other options.

From PO point of view adding improvement items to the Backlog creates difficulty in the prioritization. Can you estimate the business value of an internal improvement? The end result is that the Backlog degenerates into list of tasks to be implemented rather than a prioritized product backlog.

From the developers point of view you might question who is the customer for a improvement item. I think it’s more the developers itself than the real customer. Why should we use backlog to communicate developers what they need? In Agile we would like to people to self-organize and take initiative. What signal it sends to the developers if their needs must be prioritized and activities executed through external authority? In addition, backlog can easily be misused to execute improvement items top-down without buy-in among developers. This is a huge source of demotivation. Old Culture.

From organizational perspective long-term improvement items and short-term business value must be prioritized. Therefore we have cannot have two competing backlogs: other one on the business side and other one on the developers table.

There is no solution that fits all. In our case we try to keep backlog as a plain business backlog. Teams are taking to the sprint backlog items from the Product Backlog as well as from their own task list. These task lists are coming from Team Retrospectives, Communities of Practice etc. When PO “allows” items to the Sprint backlog also from developers agenda the problem is solved. Except from the organizational perspective. How to prioritize improvement items over business items. There I think the PO role is critical. Product Owner function should have close cooperation with all stakeholders to have a clear view also on long-term.

In Hannu’s case, first thing is to get the developers enthusiastic, motivated and passionate about Continuous Integration. Then the PO function must be aligned with the organization’s vision: having CI as a high priority. As a result, developers will get a CI that fits their needs, CI that is owned and therefore maintained and developed further by it’s true customers.

Janne Irmola, another CI driver.

This entry was posted in All, Framework and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s