Discovery techniques - part 1
When a team starts taking advantage of collaborative sessions, they can often feel a little daunting. Some teams struggle to know where to start, and some don’t feel all the bases are being covered. A collaborative session is an opportunity to really get into the meat of what a team needs to deliver as well as to understand what the value is. Therefore, teams need to spend time probing and questioning ideas to generate useful examples that can aid the team's understanding and guide delivery.
With this in mind, we created a ‘cheat sheet’ of different techniques that teams can use to learn more about their ideas, the requirements, and the examples. We’ve collated them into what we call ‘discovery cards’ that we use during the Hindsight BDD training course. Here, we want to share these reference 'cards' for techniques to get a conversation started, techniques that allow you to deep dive into ideas, and techniques that can help you generate alternative examples based on the ones you’ve already captured.
For this post, let’s take a look at how teams can quickly start exploring ideas.
5 'W's and 1 'H'
Asking a wide range of questions based on the keywords what, why, where, when, who and how can reveal unexpected information.
Example
Q: Who is going to use this functionality?
Q: How often will this functionality be used?
Q: What other functionality will be affected by this?
Use it when…
Few details are available from the stakeholder, early in the conversation.
Watch out
It’s easy to become fixated on one question type. Make an effort to vary the type of questions.
Imaginary demonstration
Asking the stakeholder to walk everyone through the demonstration they hope to see once the story is implemented. This will reveal their expectations and give you a strong starting point to ask questions.
Example
“How would you demo the feature?”
“Talk us through the demo you expect to see?”
Use it when…
The stakeholder struggles to give an initial example.
Watch out
Lots of imaginary implementation details may be mentioned; a simpler solution could be to ask follow-up questions to find the why, and then create and discuss new examples from the why.
5 Whys
Asking why? (up to 5 times) can uncover the real value or purpose behind a feature request or rule. Understanding the why can lead to useful insights such as a simpler solution or conflicting requirements.
Example
A: I would like to reward loyal guests when they check in
Q: Why?
A: Because I want to promote loyalty to the hotel’s brand
Q: Why?
Use it when…
You don’t understand the reason for doing something a certain way, or behind a request for particular functionality.
Watch out
Ask why? only until your understanding is satisfied, not always 5 times. If you use this too often people may feel frustrated by being put on the spot.
Else questions
These can help identify people and things that will be affected by your work that haven’t been discussed yet. You can combine the keyword else with 5 Ws and 1 H to great effect.
Example
Q: Who else needs to know this?
Q: What else could this be?
Q: Where else will this be used?
Use it when…
Several core examples have been discovered but you want to ensure you cover all your bases before committing to work.
Watch out
When using else, keep it focused on the people and things that matter; be careful not to use else questions to guess everything up front.
Wrapping up
As these techniques demonstrate, all it takes is a few simple keywords in a question to really open a discussion about an idea or requirement. Not all of these techniques will work all the time, so it takes a bit of practice to figure out the most effective way to use these in your team. If you are in a collaborative session, try each of them out and observe what discussions come out of it. The more you use them, the easier it becomes.
That’s it for this post, but in our next one, we’ll look at techniques that can be used to help us dive deeper into ideas and understand the motivations, emotions and value behind our ideas.
There's more where that came from...
This is blog post 1 of our 3 part discovery technique series. You can find links to these below:
Discovery technique post 2 - Discovery techniques to dig deeper
Discovery technique post 3 - Discovery techniques to reveal new ideas
About the author
Mark Winteringham, aka @2bittester , is a coach, teacher, mentor, tester and international speaker, and ranked joint 8th in Agile Testing Days 2017 list of most influential agile testing professionals. Mark has worked on award-winning projects using various web, mobile and desktop technologies and he has been an agent for change for clients across a wide range of sectors, implementing successful BDD and automation in testing strategies. Mark’s focus for the past year or so has been educating teams on how not to use BDD, and he co-developed and delivers the Hindsight 2-day BDD & Cucumber training course.
