Creating a Shared Understanding

User stories are intended to communicate a shared understanding between a product owner and a scrum team. There is a standard accepted and anticipated format that helps promote consistency, and having good acceptance criteria attached to the story defines and clarifies scope.

But there is a very good reason why one of the principles of the agile manifesto states:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Sometimes simple examples are the most effective examples. Here is something that happened to me today that made me consider the importance of communication for clarifying requirements.

First, some background. A few months ago, I created a model and a template that helps us evaluate and assess skill gaps for ScrumMasters who we’re working with. Once we identify skill gaps that we want the ScrumMaster to improve, we have specific skill-training modules (as an adjunct to our personal coaching plan) we can suggest that the ScrumMaster review.

This morning, I had some colleagues reach out to me. Here is the dialog that resulted.

Lisa – “Hi Jim, I am at a client with Jeff this week. I sat in on a session where Jeff was going through the scrum master assessment with a scrum master.  He would like to see if the dates could not be hardcoded in the legend on the graph.  Are you able to make that adjustment? Thanks, Lisa”

Jim (that’s me) – “I don’t know why you’d want to do that, Lisa.  To me, that implies that everyone will achieve competency within a six-week window.  In addition, I don’t see an easy way for me to make this change in Excel.  Not saying there isn’t a way, but I’ve looked at it a bit this morning and it is not evident how I’d make this change and still keep the template flexible for everyone’s use. What exactly is the issue with the way the graph dates extend out currently?”

Jeff – “Using today’s date doesn’t show in the graph.”

Jim – “Ok, I just tried that and you are right…that seems to break things.  That’s a different problem than what I understood described in Lisa’s note.  Let me look at that.”

Lisa and I were obviously on completely different pages in our initial interaction. Jeff weighed in with more information, and suddenly we had a shared understanding.

If we can experience confusion when communicating requirements that are this simple, consider how much more difficult a shared understanding is in the context of lots of teams working together in a large enterprise to bring a new feature to their customer.

Don’t underestimate the importance of building the right team structure, of implementing the right governance model, and of putting a process in place that enables collaboration to drive the ever-necessary shared understanding.