At some point in time most development teams run out of potential epics to do next for a variety of reasons. Alternatively they can find themselves at a road crossing uncertain about which Epic to implement next.
If you ever find yourself in either of these situations here’s a 2-hour workshop that you can run with your team. The workshop can also help create alignment in the team which can be useful in case your your team is having difficulties agreeing over what to do next.
The questions and examples in this article come from when I facilitated this workshop with one of the teams that I coach, the Network team at Spotify.
Three questions that allows your team to think clearly
The underlying assumption with this workshop is that when all members of a team works with the same dataset, what to do next will become apparent. But we don’t always realize how much valuable information we possess and that’s the first part of this workshop – to create a common dataset.
Question 1
“What related to our network have you heard people mention, read in emails or on IRC, or received as requests in JIRA in the last month?”
In our workshop the first question was aimed at our network but change the question to fit your context. Here are some examples of what the first question could sound like in other contexts:
- “What feedback have you received related to our payments system?”
- “What have you heard other teams say about the customer data api?”
- “What have we found out about our continuous deployment pipeline from our users?”
I asked the team to write down one answer per sticky. I clarified that “what” refers to impediments, praise, critique, feedback, questions, and support requests. But the team was also free to add other events or thoughts they had.
Prepare the whiteboard
While the team was writing down their answers I drew a 6×6 grid on the whiteboard. The horizontal axis was named Frequency and the vertical axis was named Impact. All stickies would eventually be placed on this grid.
If people are busy writing down their answers after you have drawn the grid I suggest that you define the frequency scale on the whiteboard.
5 = several times per day
4 = Once per day
3 = Once every two-three days
2 = Once per week
1 = Once every two weeks
0 = Once every month
If you don’t have time that’s fine. Just make sure that you share the definition when you ask the next question to the team.
Question 2
“With what frequency did what you wrote on your sticky happen?”
Pay attention to what happens once you’ve asked the team this question. My team asked for a few clarifications about what 5 means. I think the reason was that I had not written the definitions on the whiteboard in advance. If you get questions, ask someone in the group to read one of their answers out loud, and then ask him/her to asses how often that happened.
Some might be uncomfortable estimating the frequency. Point out that the estimation of frequency does not have to be exact. The team can also change their minds later if they realize that they estimated the frequency of an event incorrectly.
Question 3
-What was the impact when it happened?
We used the following scale for impact:
5 = Maximum Impact
4 = Significant Impact
3 = Moderate Impact
2 = Some Impact
1 = Little Impact
0 = No Impact
Like in the former step, write these definitions on the whiteboard while the team is busy answering the former question.
One question that I received that you might also receive is “Should we write down the impact on us or the user?”. We decided to look at the impact on our users whenever an event occurred and that’s because we wanted to identify Epics that would improve the situation for everyone using the network.
In other cases it could make more sense to focus on the impact on the team rather than the users e.g. a team with frequent incidents in a legacy system. In a situation like that I would like to know which events have the biggest impact on my team so that we could start addressing the most frequent and time consuming incidents.
Whatever you do, make a decision before you facilitate the workshop. You want to avoid discussions about the format of the workshop in the workshop, that just takes time away from the valuable discussions.
Presenting your findings
It took us around 20 minutes to answer these questions and when everyone was done one by one we stepped up to the board and shared our observations and thoughts with each others.
Recite what’s in the top right corner
When everyone was done sharing there were a lot of stickies on the board. In fact there were so many that it was difficult to make any sense from it.
The top right corner contained events that happened often and that had a high impact on our users so that was the area we focused on.
I stepped up to the board and read out the stickies in each of the cells. As I had read a few cells I stopped and asked the team what patterns they saw and which conclusions they drew based on what I had just read out loud.
The grid allowed the whole team to focus their discussions on events that happen often with high impact. Thanks to a shared understanding of the problem the team quickly transition into problem solving mode. In our case it took us minutes from when we had identified the problem until the we had identified and agreed on a solution i.e. an Epic. And this was just for the first few cells.
Identify your users and stakeholders
Once you have the first epic ask the team who would benefit from the solution – their answer is most likely user. If the team is not able to answer, look at the stickies on the board and ask the team who they were thinking of when they wrote the stickies.
Once you have the user, ask the team who might have opinions about the technical implementation or on the impact you are trying to make with your epic. The answer to that would be the stakeholder.
Create your Epics in this meeting
What you should wind up with after this discussion is an Epic that contains a problem statement, a solution, a user, and a stakeholder. Ask someone in the group to both summarize and write down the epic and put it up on the grid on top of the cells.
Repeat until you have enough epics
Some teams work on one epic at a time. Others on multiple. Some teams need to prepare and sync with other parts of the organization and others don’t. If your team normally works on one epic at a time and the epics normally take a long time to complete this is a good time to end the meeting.
If you want to identify more epics just step up to the board and read out the stickies for another area and repeat the exercise. When I facilitated the workshop the team was able to identify 3 different patterns, each leading to an epic of its own.
Final words
This workshop attempts to capture your teams combined knowledge about your product, stakeholders, customers, and users. Done successfully, and with a wee bit of luck, you’ll come out of workshop with your next epics. You will also have reduced the likeliness of your team disagreeing on your next steps, later down in the process.
8 tips in case you want to try this workshop out for yourself
Tip 1 – Make sure you have enough time.
Book 2 hours, and the workshop is active/engaging so there’s no need for a break.
Tip 2 – Get a guest facilitator if you are actively involved in the product.
If you have knowledge about the product, stakeholders, customers, or users, ask someone else, preferably someone that is not a part of your team, to facilitate the meeting for you so that you can contribute.
Tip 3 – Pre-print questions and definitions.
This is particularly important if you’re facilitating this workshop for someone else. Decide on which question you want the team to answer and then note it down so that you can use that exact phrasing in your workshop. Do the same with your definitions to questions 2 and 3.
Tip 4 – Make sure your room has a big whiteboard.
You’re going to need a lot of space it to visualize all the data that comes up in question 1.
Tip 5 – Use different colors on the stickies to gain bonus insights.
If you think back to my first question, I wanted the team to note down what they had heard, received over emails, on IRC, and in Jira. By using different colors for each of the sources i.e. yellow stickies = IRC, green stickies = email etc. I could gain insights on how my team engages users or the other way around.
Here are some examples of what insights we could have gained:
- the most frequent way our users contact us is via Jira
- the most common complaints has a very low impact on our users
and so on.
Look at your question and decide if you want to track sources via colors on your stickies.
Tip 6 – Start with a few improvements.
We identified 3 improvements. The three epics will likely take us at least a quarter. A lot will change in a quarter, don’t spend longer than you need in this meeting.
Tip 7 – Don’t break down the epics you identify in this meeting.
This is a workshop where you identify epics. Don’t break them down now, save that for later. Focus on identifying user problems, user needs, solutions, and users. Break down your epic when you have agreement and alignment.
Tip 8 – Make sure you are in agreement in this meeting.
Ask all participants to thumb vote. Thumbs up means “I agree that we should do these epics next”. Thumbs down means “I disagree. I don’t think these epics are the ones we should focus on next”. Or decide for yourself what thumbs up and down means.
The point is that you should make sure that everyone’s voice has been heard in this meeting. You don’t want a few to disagree in silence to later on disagree.
Thanks for reading!
Source / acknowledgements
To create this planning format I took inspiration from a retrospective model that Esther Derby and Diana Larsen created called FRIM. It’s short for Frequency Impact, but I modified the questions.