4 workshops to destroy Silos: 4/4 — The Example Mapping
Finally, almost done! And yes, I am talking about 2020 indeed 👀 But also about the 4 workshops to go from an initiative to its implementation. So last time we discussed about the Story Mapping (that was 2 months ago already 😯) and today we are going to go through the last step which will help you to create a detailed version of a User Story (or whatever it is you are using to explain and describe your needs).
So what’s an Example Mapping
It kind of look like that actually 🙂 The objective of the Example Mapping is to discuss a user need based on how you’re going to test it in order to define what needs to be done and how. Once again, I’m not going to go too much into details (I’ll leave you a few links at the end of the article 👇) but still, let’s go quickly through the main steps.
1. Present the US again: a job for the PO 👩🚀
So remember, during the exercise you will focus on one US at a time and the very first step is to explain it again to refresh everyone’s memory. Sounds obvious right? So start the session by asking the Product Owner and/or any business stakeholder to present the topic and make sure it is clear for all the attendees. Don’t hesitate to ask a few questions, maybe ask one of the participants to formulate what was said with their own words and see if there are any general question. The important part here is that the objective of the user must be understood, we know what he wants as a result of this specific story and why, this will be the core of the rest of the discussion.
This part should not take too long (10 minutes tops) but is important and serves as a great kickoff for the workshop.
2. What are the rules? 🤔
Ok so the objective is clear, we already asked questions regarding the end result, now is time to define what are the limits of the story. What should NOT be done (is out of scope), what we HAVE TO conform to (could even be for legal reasons), basically what are the Acceptance Criteria or AC that apply to the story.
Let’s say you’re building a chat. The first story is about the capacity to send a message to another user. Well there are a few things that comes to mind right away:
Do we consider notifications as part of the story (confirmation that the message was sent and or received)?
Are there any RGPD rules that apply?
Can the message be a reply of another message?
Is there a limit to the amount of characters I can send?
…
A lot of questions can be raised here. Some of those will turn out to be another US entirely or, as I said before, completely out of scope (it’s not even something we are considering right now) so it is important to go through all of them, even the ones that feel out of place just go ahead and ask away, if it’s not clear for you chances are you are not the only one!
3. Test, test, test 🧪
Ok, now comes the fun 🥳 Well, it can be anyway…The objective of step 3 is to come up with as many examples as possible around the AC. Take each one of those and think about real life examples, edge cases, anything that you can think of and write it down.
The limit is 500 characters, if I try to write 501 nothing happens (the character does not show).
When I write my message, starting at character 450 a message appears in orange saying “Max 500 characters”.
After I send a message it is displayed in the chat and a little message appears just below saying “Message sent”
…
Iterate until everyone feels satisfied with the result and cannot think of anything else of interest. Each example that you just write down is a test case that will be used to validate the story, see, that wasn’t so hard.
4. Now, let’s talk implementation 👩💻
Ok, now that things are clearly defined, we can go to the last part of the exercise and talk about what needs to be implemented and how in order to satisfy the AC and examples that were just defined. For this discussion you might not need everyone as it is mainly an IT conversation. At the beginning I still liked to have everyone in the room, best way to answer questions when needed. But with the experience I must admit that it is not necessarily interesting for everyone and questions can, most of the time, being asked asynchronously (send a slack or something and keep working while you get the answer). Just ask people to stay available if needed and let them go find their happiness in the world 😆
I know you noticed it, we kind of used a TDD / BDD approach here. Well yeah, we did, it’s a great way of doing things! Start With why, then make your way up to how, by doing so you will really focus on answering to the initial need of your user and not adapting it to the constraints of you system.
A few advices
You are done, good work to all of you you did it 💪 And it wasn’t even that hard now was it? Now, there are a few things to keep in mind, specially if you’re trying this workshop for the first time so you don’t feel like a total failure and consider changing career to become a professional Tap Dance performer (yes, it did crossed my mind once).
Creating the dynamic can be hard!
It depends a lot on the dynamic of the persons you’re doing the workshop with obviously but still, having people understand the exercise, come up with questions, examples and so on can be quite tricky. So don’t get discouraged if you feel like the energy is kind of low, keep asking question, try to create interactions, and if it’s not a success the first time that’s ok, they will get a hang of it at some point.
3 amigos comes a long way
Ok this one is veeeery important: 3 amigos is a very powerful tool! You should always make sure to have the right people around the table but in this case it will definitely make the difference between success and failure. So yeah, QA, PO and developers must be involved in the discussion, that’s for sure. Oh, and don’t forget to invite business stakeholders, if this is really a priority they will make time to be there! And if they can’t just work on something else, it means there are more important things for now (and that’s ok by the way).
Great way to split stories
We already talked about that but I want to emphasize it again, the Example Mapping is a great way to split your stories. Use the AC and examples as a way to challenge the story, maybe it’s getting too big or it is kind of confusing, when you feel like that’s the case decide what to focus on first and separate the rest in another story, remember that it is better to have a small part of a feature working and ready to be delivered than the whole thing done the wrong way.
Don’t forget NFR
Unfortunately we do more often than we care to admit. Although we know that Non Functional Requirements can have a huge impact. If I go back to the chat example, asking something like will our server be able to support the activity of the chat is a pretty damn good thing! The NFR can be constraints that are worth considering when designing a solution and it should most certainly not only be the concern of tech people, all the persons that are interested in the feature should be aware of them. So don’t forget to ask what kind of requirements / constraint we might be facing and add those to the discussion when defining what you’re going to do.
That’s it
You finally did it, yeahhhhh!!! That was the last of the workshops, congrats! I know it can feel like a lot but remember, you don’t have to do all of it (adapt to your needs and the needs of the topic) and if you apply this to a controlled scope (meaning not too big!) then it should not be that long and it will definitely bring a lot of value and generate more collaboration in the organization.
I hope you liked it, please let me know in the comments what you think, and don’t forget to share your tips, I’m always keen to learn some new tricks 😉 Oh, and as promised here are some links to go further with the Example Mapping.
A nice article on the blog of Xebia:
https://xebia.com/blog/example-mapping-steering-the-conversation/
This great video by Scrum Life (in French):
Did you like this article? Show it
Leave a comment, like on LinkedIn 👍 and share! Your help and feedback is important, it helps me learn and keep improving, thank you 😀
