Conversation Count - Improving Backlog Item Quality

In a recent class I was chatting with a student about a situation they were running across, and it was similar to other scenarios that may have come up with your own teams and organizations:

The team was having issues completing backlog items because they represented more work than they should have taken on in the upcoming Sprint.
The team sometimes has backlog items that they finish very quickly when they originally thought it would take much longer to complete - The team had trouble figuring out if they were actually "done" with an item.

So I asked the student: "How many times would a discussion happen about these backlog items prior to Sprint Planning? A handful? More than say two or three?" The answer I got:

"...it's actually closer to zero..."

Needless to say I wasn't completely surprised by the answer, as I have seen this as a characteristic of teams struggling with the interpretation, execution and verification of backlog items. Which bring us to what I think the problem is:

Product Backlog Items of suspect quality are making their way into the Team's Sprint Backlog

There are a number of reasons that this might happen, which could include: - The misunderstanding of the Product Backlog and Sprint Backlog artifacts- Someone forcing the team to take on work- The organizational commitment (or lack of) to implementing Scrum

At the end of the day, there is rarely enough constructive discussion focused on mutual understanding of what a particular Product Backlog Item (PBI) represents. Missing out on this opportunity to "get on the same page" has a domino effect on the activities and conversations that happen down the road. The impacts on your Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective will all feel the impacts of these suspect quality PBIs.

I'd like to offer up a technique that I've given to a number of teams to experiment with. Try this:

Count the # of conversations your team has about a PBI before it enters the Sprint Backlog

You can use this "Conversation Count" with respect to each PBI that gets accepted by the Product Owner during the course of the Sprint. This may lead to some interesting insights, especially with the relationship of the number of conversations to acceptance rate. Imagine this example: - For PBI that had a Conversation Count of 0, the team had 0 of 2 items accepted- For PBI that had a Conversation Count of 1-2, the team had 1 of 2 items accepted- For PBI that had a Conversation Count of 3-4, the team had 2 of 3 items accepted- For PBI that had a Conversation Count of 5+, the team had 4 of 4 items accepted Note: this is an example that could really lead to some conversation about backlog item quality! Now when I say "Conversation" I don't mean a one-sided discussion where party A hands someone a card and says "this is what you are going to do, nod if you understand". I specifically mean a two-way street where the goal is to reach a mutual understanding about that specific backlog item. Focus your discussions in a few key areas to get the ball rolling. As a team, have a conversation about:

Who this item is for, whose life is enriched by completing this PBI
What it is that this individual would like, what actions they are trying to do
Why this individual needs this, what is the value of it, how it makes their life better
How we as a TEAM can verify that this item has actually been completed, what "DONE" means
How it compares with other backlog items in terms of relative complexity (estimating)
If we as a team think we can get this PBI completed in the upcoming Sprint

Give this a try, and if your team experiments with this "Conversation Count" I'd love to hear about it! Sharing experiences like this with others can often inspire others to give their own experiment a try, and if it helps make lives better then it's all worth it. - CL