Practice Mapping – An Experience Report
Following on from the Practice Mapping article, here are a few examples of the kind of thing you may see with teams you work with.
You may have thought “Why bother with this particular game? Just give people a standard ‘right’ answer!” We could do that but seeing a diagram or reading words doesn’t necessarily change our views and often we hold on to our original thoughts about a subject regardless of new information coming in. The power of this game is to see inside the mind of others and have useful discussions about the results.
We’ve redrawn a few snippets of the diagrams we have seen that show people’s thinking to illustrate some common misconceptions and the types of discussions we could be having as a result of playing the Practice Mapping game.
In this snippet we can see someone correctly using the terminology of the Product Owner role accepting a Product Backlog Item as Done and they have indicated it is as a result of the Sprint Review activity.
In this case we’d discuss with the team when is the best time to accept items. Do they really mean it should happen only at the Sprint Review? What problems might we encounter if we do it then? They probably have a few tales of items not being accepted with only minor changes needed, but there is no time left in the Sprint to fix them. So how can we improve this? The obvious answer is to get acceptance as soon as the team think the item is finished and ready for acceptance and not wait for the Sprint Review. The team then make steady progress every few days with an increasing number of Product Backlog Items accepted as Done, and they have time to fix any that aren’t accepted within the Sprint.
In this snippet around Product Backlog Refinement we can see that they have illustrated that the Product Owner creates Product Backlog Items during this activity.
On the surface this looks like the Product Owner does all the work which begs the question to the team of who else needs to be involved? The clue is on the card where it says it is “A whole team activity led by the Product Owner”.
In this final snippet focused on the Daily Scrum we can see that this team describes it as being facilitated by the Scrum Master and the Dev Team attend to coordinate the work and raise impediments.
That doesn’t sound too unreasonable and is often the language people use but it does call for some probing questions to the team.
Does it really need the Scrum Master to facilitate? Couldn’t the Dev Team run this themselves with the Scrum Master ensuring it has the appropriate outcomes? Maybe this is why the team have used quite a passive word of ‘Attend (someone else’s boring meeting because Scrum says so!)‘ rather than something more active like ‘Participate’.
Also, you may question what the team’s view is on having any other people at the Daily Scrum. The most obvious person is the Product Owner but they didn’t appear connected on the diagram. Was this an oversight or do the team really think they should not be there? There is no right one answer and it depends on the situation, but the Product Owner is part of the team and often there is much value in having them available at the Daily Scrum, especially if there are many questions on the ‘what’ rather than the ‘how’ that can be dealt with immediately.
The Essential Scrum Cards are completely in keeping with the Scrum Guide so are the perfect tool to help in learning Scrum and highlight understandings, misunderstandings and viewpoints while playing the Practice Mapping game.