I’ve been pondering for a while now on what will be the most successful method to transfer our findings from our discovery sprints to my fellow product owners… I work on a pretty big project and we have a team of several POs who each work with their own scrum team. Since one scrum team cannot handle the work required for the functionality me and my team have been researching, we need to be ready to hand most of it off to other teams. We already handed over a couple of smaller pieces of functionality to be developed, with satisfactory results, however the remainder of the items is significantly more complex and therefore I expect it will be much harder to successfully transfer all the knowledge over to our colleagues.
One thing I found challenging is how to educate the team on the priority of the various epics and stories at a glance. We do prepare and provide them with the key user stories we believe are going to drive success, however it can be overwhelming to go through a big excel sheet of data, trying to figure out which items are the most important, which are related to or dependent on one another and what would be the most logical and effective sequence to work on them – not to mention the fact that often these epics and stories need to be slotted in next to other items on the team’s backlog slated for the same release…
I hadn’t yet come up with the ideal solution, so I went snooping around the web and came across this article on the ScrumAlliance website by Andrea Gigante about using story mapping to manage the product roadmap and release backlog. Being a very visual person myself, this approach immediately struck a cord with me, as it represents the product backlog not as a long list of items, but a clear visual grid, already prioritized by both feature and story.
I was hoping to find a model that provides a quick yet comprehensive understanding of the functionality we are targeting, which stories are related to which epic and their respective priorities, but without going into too much detail, so as not to interfere with the teams’ individual estimation and sprint planning processes. This application of story mapping may provide me with just that: my team can provide the basic structure of the story map by feature and related stories, whereas each scrum team can then go their separate ways and slice and dice the pieces as it fits in their sprint schedule, based on their estimations and velocity expectations.
I think this easy to grasp concept will be a great basis for handing over my team’s discovery work to our other scrum teams and POs, which we need to be ready for in a few weeks, so thank you Adrea for sharing!
I will report back when the transfer is complete.