Shared Understanding

In a previous post I mentioned a post on Mike Cottmeyer’s blog entitled The Real Reason We Estimate. If you haven’t read it yet I highly recommend it. In the post Mike mentions that often, if the team’s estimates are not accurate, it is because the team lacks a good shared understanding of the story. We have definitely experienced this on our teams. So what are some things that we can do to improve shared understanding?

The Big Picture
The most important first step in getting a shared understanding is ensuring everyone knows the big picture. There are many ways this can be communicated such as a charter (a light weight agile one of course, potentially something like the Agile Inception Deck discussed by JR in the Agile Samurai), a release plan, or a story map. Any of these tools, or a combination of them, can do a good job of keeping the team from missing the forest for the trees. I personally really like story maps. We don’t necessarily go all the way down to the level of individual user stories being brought into iterations on our story map, but we have started keeping track of what item on the story map all the individual stories support. We have also recently started color-coding the items on the story map to track the status. This way we can see at a glance how we are progressing along the story map.

Design Workshops
Also known as backlog grooming meetings, we have regularly scheduled design workshops (this name seems to better representing what is done during these meetings) during which the entire team spends time discussing the stories on the backlog. Depending on what is required at the time, many different things are done during this meeting, and often a combination of these these are done in any given meeting.

First, if necessary, we spend some time on the near-term stories ensuring there is a great level of shared understanding and that there are no large unknowns that would keep the story from being able to be pulled into a sprint. Many times this is just a quick update with answers to any questions that were brought up in previous design workshops. Minor unknowns or questions at this point are alright, as long as we are confident we can have answers to those questions by the planning meeting.

If there have been any new stories added to the backlog, we spend some time discussing them and getting high level estimates on them. This way we can stay on top of new stories and ensure our backlog is completely estimated which helps me, the product owner, make priority decisions. A lot of times this is just very quick conversations in which I explain the business problem, answer some quick questions, and then the team estimates by playing planning poker.

Another thing we do during this meeting is break down large epics. As epics approach the team will discuss them more and start to break it down into smaller stories. I will usually have thought more about what stories make up the epic and will have those cards ready. The team can then discuss and estimate the stories so the I can prioritize them in the backlog appropriately.

Finally, we also will often use this meeting to take a step back and look at the bigger picture. We will pull up the story map and/or release burndown chart and talk about anything that has changed on it and how we are progressing. As the product owner, I will often share any new market information I have gathered recently talking about which items on the story map this information supports or brings into question.

Taking time to do this with the team on a weekly basis really helps keep everyone on the team focused on the big picture and up to date on any changes that may be occurring in the vision. There are many tools and techniques that can be mixed into these meetings as well. If there are any other things that your team finds helpful in backlog grooming meetings, please leave a comment and let me know, I’m always looking for new things to try!

0 comments… add one

Leave a Comment

Previous Post:

Next Post:

%d bloggers like this: