How do you get started with discovery on your Scrum team?
Participants learn how to improve practices like user research and interviews, persona sketching, design studio, prototyping and story mapping by actively using them in a class. At the end of the class, participants see a different way of working. Then the discussion turns to something like- While this is undoubtedly is a better way to work, it’s so different than what we do today. How can we do this stuff where we work? How do you get started?
An easy answer- include discovery in your Scrum Ceremonies
While I usually don’t like to prescribe what to do, this time you’re in luck. If you’re really that good with Scrum, producing shippable product at least every Sprint and serious about continuous improvement through your inspect and adapt cycle, include discovery in your existing Scrum ceremonies. That’s it. If you get it, you can stop reading and go try it out. If you need a little more encouragement, let me explain further.
Perhaps you’ve read about course or a conference on the subject. And now, you want to try to introduce discovery on your team.
Start by retrospecting on how discovery might help
I like to introduce an invitation to try changing something during the retrospective. Try brining up the idea and invite people to consider it during this time. You know why you want to do it. Does the reason resonate with other people? Do they see the same need? If so, then you can discuss what practices you would like to try, and then plan it in to the Sprint.
Add discovery items in Sprint Planning
During Sprint planning, discuss what you’d like to do, how long you’d like to take to do it, and get it on the Sprint Backlog with everything else. It could be under a general discovery Product Backlog item, or as tasks to something specific. Leave room for it. If everyone on a team of seven wants to get out of the building and talk to users, why not start with a user interview task of seven hours? Can you afford to spend an hour out of your Sprint trying it?
Discuss them at standup
As the task (or tasks) are put in progress, discuss them at the daily standup. One thing I like about talking through discovery tasks at standup is that it gives a voice to the Product Owner to talk about what they are working on. Go through the normal standup first. Allow for those that don’t have discovery items (or interest in them) to go back to work if they want to. Let’s keep the spirit of self-organization, after all.
Review discovery items after the demo
At the end of the Sprint, review your discovery results. Maybe it’s a new persona, or a story map. Whatever it is like a new story map, landing page, or results of interviews- show it in the Sprint Review. Once again, do this after reviewing the product. This is a good time to get the input of stakeholders or customers. It’s a MUCH easier time to incorporate feedback, than after you’ve gone through all the hard work of building, testing and deploying the features.
Retrospect on how to improve your team’s discovery practices
Then, it’s on to the retrospective once again. You can discuss how the experiment of adding in discovery to the Scrum framework went for you, and how you can improve it for the next time around.
Have you added in discovery practices on your Scrum team? How did you do it? What advice would you give those who would like to try?