I’ve written a lot about product ownership, product backlogs, and user stories over the years. But the other day it struck me that I hadn’t shared something that has worked well for me for many years.
It’s an idea that is coupled to two notions—product backlog refinement and the 3-Amigos metaphor for story evolution.
I noticed in several companies I’ve worked for that teams struggled with getting the stories effectively delivered. There seemed to be, for lack of a better phrase, a lack of ownership in story delivery. That is, stories often missed the mark in functionality, quality, integration, etc. And when we discussed this in our retrospectives, there was a lot of finger-pointing and blaming, but no real solution ideas.
I believe I tried this first at a company called ChannelAdvisor around 2007-2008. So, you can see why I’m surprised that I haven’t thought to share it until now.
The idea was to have one person on the team serve as a guide or Sherpa for an individual story. No, they didn’t do all of the work. But what they did do was “guide” the story through execution by working with team members and the Product Owner. They ensured that the right people were collaborating around—
The refinement and Readiness for the story
The execution of the story to meet the Definition of Done
And the Acceptance/Sign-off and demonstration of the story
Essentially shepherding it through delivery and ensuring it met the customers’ needs.
Anyone could and often was a Story Sherpa—developers, testers, Business Analysts, architects, whoever. We shared the responsibility across team members and it was a voluntary role. Usually, it surfaced when we first examined a story in the initial refinement meeting where it was introduced.
While they certainly could be a Sherpa, usually the Product Owner and Scrum Master did not assume the role. Instead, it was a “team thing”.
And the role shouldn’t be taken as something outside the bounds of the team. It’s a soft-role that is intended as a reminder within the team of doing and delivering good work.
I’ve found this to be a lightweight adjustment that really makes difference for a beginning-level or moderately experienced agile team. At some point though, teams shouldn’t need a Sherpa role.
And if you don’t like the name Sherpa, here are a few others that might be more palatable—
I’d encourage you to try this idea as an experiment in your next iteration or sprint and see how you like it.
Stay agile my friends,
About the Author
Bob Galen is an agile practitioner, trainer & coach based in Cary, NC. In this role, he helps guide companies and teams in their pragmatic adoption and organizational shift towards Scrum and other agile methodologies and practices. He is a Principal Agile Coach at Vaco Agile, a leading business agility transformation company. He is also President and Head Coach at RGCG a boutique agile coaching firm. Bob regularly speaks at international conferences and professional groups on topics related to software development, project management, software testing, and team leadership.