A whiff of Implementation details

tl;dr: Implementation details in your product backlog items are as signal that your Scrum team is not collaborating enough on product backlog refinement.

When developing or refining a product backlog I have regularly encountered the problem of “implementation details” in product backlog items. This problem usually looks like a member of the development team crankily addressing the Product Owner about content of a user story. I think this highlights a misunderstanding in how to work with a product backlog and work in a Scrum Team, I don’t think the problem is the one most people think it is.

For most Development team members “implementation details” are about having the Product Owner telling them how to do their job. This is a legitimate concern because we want everyone in a Scrum team to be able to work with a degree of autonomy even though their work is interdependent.

From the Product Owner’s perspective the detail they want in their product backlog items is used to describe the product increment the item creates. This means they will want to make the item as descriptive as possible of their idea. Once they get into this detail the Product Owner may start to describe what can be construed as details the Development team would work out.

The problem is not that there are “implementation details” in the product backlog items. The real problem is how this information gets there.

The crux of the problem is a lack of collaboration. A product backlog item needs to be an enabling specification such that the Development team can get on with building the product increment with little need to go outside the team. To create a product backlog item to this standard requires more than a Product Owner burning the midnight oil the day before Sprint Planning. To achieve this requires ongoing collaboration across the Scrum Team.

When a team collaborates on the product backlog they start to record information they need to remember during the Sprint. This information may include “implementation details” and in this situation the information is collaborative identified and recorded. I don’t know where I picked the phrase up but I often describe this as “write to remember” and I contrast this with “write to communicate”.

To get this collaboration happening the Scrum team needs to spend their time refining the product backlog. The team has up to 10% of the Sprint to work on this. For a 10 day sprint this is one day! Imagine how much refinement the team can get done in a day. “Are you recommending we spend a day per Sprint refining? That’s nuts”. I am saying you have up to a day (in a 10 day sprint) to get the product backlog in a useful state. As much as Scrum is about building product increments it’s also about building the product correctly and efficiently and that’s what this time gives you so use it well.

Comments are closed.