when relevant content is
added and updated.
While I was in Postdam, Germany for Agile Testing Days 2015, there was a blizzard of options for talks and workshops I could attend. With close to one hundred speakers, there was no way I could attend everything I wanted to, but one workshop in particular stood out to me. It was delivered by George Dinwiddie and Stephan Kämper regarding The Three Amigos Principle.
I figured I’d learned everything I’d need to know about this concept years ago. It’s pretty simple. A programmer, a product owner and a tester walk into a room… and no, this is not a set up for a joke, that’s what they do. They get together and discuss the details of a story, so that everyone can be on the same page. In my company, we most often have this interaction when a story is “kicked off”.
The idea behind the Three Amigos principle is that software testers and programmers can get involved in the process of defining, developing and testing stories earlier. What often happens, though, is that a story is reviewed from a high level, some questions are asked, and the general consensus is that we can get into the details as we progress.
As I was listening to George and Stephan share their experiences and some examples that they put together for us to work with, they shared an idea that I felt was quite powerful, and made a lot of sense. It’s called “Example Mapping”, and was developed by Matt Wynne.
Example Mapping is the process of taking a requirement and creating specific examples based on the information provided. It could be done in the Three Amigos meeting itself, or it could be done as a preparation for the meeting. The process we used in the workshop was to start with a high level idea (in this case, we were looking at at parking garage and the rates they would charge, including peak usage times). The top level of the example was the name of the feature. The next level was the variations we could consider. We represented these variations with index cards, which allowed us to move them around and see them in association with the top level feature. As we considered each example, we would create slightly more detailed explanations and add to the examples, with each flow step being added to another card and placed underneath the section we were considering.
This may seem obvious, but one of the cool things about doing this exercise was that it allowed us to look at options we would have previously glossed over. It gave us some specific questions to ask, as well as a way to get a better focus on the feature as a whole. Was what we were proposing too large for a single story? Could this be broken up into smaller pieces? Had we identified all of the workflows that this feature would represent? As it turned out during the session, even a simple example could have many more permutations that we had at first considered. With the parking example, we realized that implementing peak hour changes was a significant deviation, enough so that the general rules would need to be adjusted to allow for it, and that testing the options to be accurate might take more time than we had at first anticipated. Our group even considered the idea of handling the times (standard and peak) as two separate stories.
What this process allows us to do is step back and make sure that we can better understand what a feature should be doing. If we don’t have a clear understanding of that, we can then gather questions about the requirements and present them.Using Example Mapping, we avoid the trap of “rubber stamping” that may happen during our story kickoffs.
I’ve since brought it back to my own team, and have seen first hand the change it is making to discussion, both leading up to our Three Amigos meetings, as well as during those meetings. Perhaps you may want to give this a try, and see its effect on your fellow Three Amigos.