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:
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:
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:
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:
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