Following on from my previous post on the top talks at CukeUp Australia 2015, this post covers what I learnt from two of the workshops.
There were 4 workshop sessions over the two days, with two options available at each time. The workshops were 90 minutes of hands-on practical learning and they helped to balance the conference between talks and getting stuck in and learning new practical skills.
BDD in the Key of Design – Integrating DDD and UXD (Paul Rayner)
You can download the participant’s workbook for Paul’s workshop here.
The techniques we tried in our workshop included the use of Personas to help understand users and develop valuable scenarios.
In our case we worked on fleshing out the persona of “Bob”, a user of the library website that was the system our exercises were based on. We started with some basics like deciding his age and family. However we quickly dived into much more detailm including his preferences in DVDs and why his travel for work combined with his kids’ love of books was causing him to get so many library fines!
Not only was it fun developing Bob’s persona, but it made the exercise of developing scenarios much more like storytelling. I found working with a persona made creating new scenarios and thinking outside of the “obvious” scenarios much easier than if we had been developing against a dry set of business requirements.
In developing our scenarios for Bob, we also used simple wireframes to help facilitate the discussion. Starting with an example wireframe of a fines & fees summary screen, we worked on wireframes for Bob paying them.
Having a sketched implementation helped to make the scenario more real. We could work with Bob as a persona and imagine him working through paying his library fines, including asking ourselves questions of design from his perspective – how could we make the payments process simple? what options would he want for payment? how would he have confidence in the payments being secure?
As we worked with the wireframes we noticed parts that we initially thought fit, didn’t really fit on closer inspection, and we also noticed where there were gaps in the process.
We split into pairs while working on the wireframes and came back to our table to discuss the wireframes we’d developed. This turned out to be an exercise in the technique of set-based design.
Set-based design is an approach where instead of working on solutions straight away, we work to develop a number of options and narrow in on the eventual solution. In our case, each table had 3-4 options from the wireframe exercise as our starting set of options.
The benefits of this approach were obvious from our exercise. When working as a group (especially with an unfamiliar domain and unfamiliar people) it can be very easy to fall into “groupthink” and move to reach consensus before critically evaluating all the options. Coming back as a group with multiple different perspectives on the same business problem, we could compare our approaches, identifying the common parts where there was wider agreement and discussing the differences in working out a combined group design.
For our final exercise we tried the technique of Event-Storming.
We worked as a team on telling the story of how our persona Bob had accumulated library fines to a level where his card got blocked. We brainstormed events that could have lead to that situation and laid them out in the order the group agreed on. This gave us a timeline of events that modelled a simple workflow through our system. While we ran short on time to evolve alternate workflows we’d already started to find events that didn’t fit our main workflow, but could be the seeds of alternate workflows.
I found event-storming a natural extension of the work we’d done with personas, being another approach based on story telling. It was an easy technique for our group to pick up and start modelling workflows collaboratively, with little direction required.
and more …
Some other ideas looked at in Paul’s workshop included:
- Naming concepts in your business domain to make the implicit explicit. In our Library example this included concepts such as an account being “deactivated” and a card being “blocked”.
- Our exercises were timeboxed and that help us to keep focus and not over-engineer ideas
Using free text space in feature files
- Paul’s session was one of many in CukeUp (including Matt Wynne’s workshop) which emphasised the value using the Feature description free text area in a Cucumber feature file to detail business rules and other relevant details.
- This approach helps to set better context for scenarios without having to make the scenarios themselves too wordy.
- Discovery within BDD
- We focused on the Discovery phase in the workshop, developing and exploring options, rather than trying to come up with solutions and formalise scenarios straight away.
- An overview of cycles within BDD
There was a lot covered in Paul’s workshop, and while nothing was covered in great depth it was an informative and fun sampler of a range of techniques for further investigation and use.
The team I currently work closest with is relatively quiet and I think that techniques such as set-based design could help in giving all the team an opportunity to develop options, rather than having the more outspoken members driving discussion.
Example Mapping (Matt Wynne)
Matt’s workshop focused on Example Mapping, a structured technique to get the most out of “3 Amigos” sessions and effectively break down user stories into rules / acceptance criteria and examples.
Before getting into trying Example Mapping, we looked at the purpose of a 3 Amigos session and the types of outcomes we’re looking for from them.
Starting with a story, we’re aiming to:
- define / refine rules or acceptance criteria for the story
- produce examples to confirm those rules are met
- identify questions and get them answered
- potentially split the story or create additional stories
with an overall goal of creating a shared understanding of the story.
What Matt highlighted is that while we have these outcomes in mind, we often focus much of our effort in 3 Amigos sessions on writing nicely structured Gherkin (Given/When/Then) examples at a cost of focusing on discovery.
Our first exercise in the workshop looked at the relationship between rules and examples. We worked on developing rules for a “strong” password. Our task was to create 3 rules and try to communicate the rules to another team using only examples.
While some of the rules teams chose were straightforward to pick from the examples (e.g. a minimum number of characters) others were too complex or too obscure and we found we didn’t have enough examples to adequately communicate all the rules.
This exercise emphasised how BDD is about much more than examples, and that it can be hard to know if you’ve provided complete coverage of rules with examples.
Example mapping is a technique to structure the conversations in 3 Amigos sessions – mapping the rules and examples for a story and to identifying the questions we need answered.
In our exercise we worked through with different coloured cards for each element in our maps to make the purpose of each card clear – the story (yellow), questions (red), examples (green), rules (blue).
The mapping is simple – the story goes at the top, below that is a row of the rules, for each rule we have a column of examples, with questions to the side of the main map.
We developed an example map for getting a refund on a kettle. A mundane and seemingly straightforward story which evolved quickly into a complex scenario over the course of the workshop.<
Rules generated examples and examples generated rules.
As we created examples for the initial set of rules, we found some examples we created generated questions for our product owner. Some of these question lead to refined or additional examples, and some lead to new rules being defined. I forget whether it was Matt or one of the participants who said it, but this process was summed up nicely as “examples start conversations, rules close them“
As the map of examples and rules grew, it also became apparent that the scope of the story may be too large … the fact that we were quickly running out of physical space on our table for the map was a good indicator! While we didn’t have time in the exercise to actually split the story, our map had clear lines along which we could do the split and once a split was done we would have had well-developed starter maps for those stories.
So we had … a story (via an example map) generating more stories.
Our team’s rapidly growing example map. We generated a lot of questions (pink cards) and as those questions were answered (the pile at the bottom of the picture) the map grew wider and deeper
While a simple technique, I found example mapping was highly effective in facilitating the team’s conversation. It clearly highlighted where there were gaps in examples coverage and in our understanding of the rules.
I’ve discussed Example Mapping with members of the teams I work with and there is interest in trying it for some of our stories. In particular, we are thinking the structure of Example Mapping may suit teams who tend to lose focus in 3 Amigos sessions.