I often struggle with clarifying expectations; where do you start, where do you stop? Teams often end up with too much or too little detail and big gaps in what people actually do.
The solution: story map your expectations
I wanted something that would give my sessions a structured framework; enter Jeff Patton’s story mapping. My thinking was if it worked so well to create tasks into a holistic view, why not role expectations? I adapted it to create an ‘Expectations mapping’ workshop and have found it provides a backbone that allows a group to create a shared view of expectations in a structured way.
How to run an expectations mapping session
Here is how you run the session. The key is real-time interaction and visualization using stickies; so go old skool with an in person workshop or use an online collaboration tool like Miro or Mural.
Step 1: Frame it up
First up before you run the session, agree the scope of the area you are mapping expectations for; e.g. product delivery. This will help focus the session and ensure you get the right participants along.
Step 2: Establish the Roles
Define the roles that you want to include, keep it high level and make sure you involve the person who has that role in the workshop itself. You might identify additional roles as you run through the workshop; if you do make sure you loop them in through a follow up session.
Example roles for product delivery team
Step 3: Map out the Activities
Identify and map out high level activities. I’ve found it useful to start with a value stream map, the sequence of activities undertaken to deliver value to the customer. Then layer on any other supporting activities that are done to align, or support stakeholders.
I have found phrasing these activities as questions using a “How do we…” format and sub-questions to help prompt brainstorming for the next step. Make sure you use the language of your environment for these activities and ensure a shared understanding of what each one means. The core set of activities and questions I have found useful as a prompt for product development teams are as follows:
- How do we discover?
How do we uncover what is desirable, viable and feasible?
What tools and techniques do we use to refine the product backlog?
- How do we prioritize?
How do we ensure we are building the things of most value?
How do we define value and decide what to do next?
- How do we communicate?
How do we communicate with each other and with our stakeholders?
What tools do we use, what information do we share and why?
- How do we track progress?
How do we ensure we are making progress?
How do we review what we have built and get feedback, what metrics do we use?
- How do we build it?
How do we ensure we build a quality product?
What standards do we use?
- How do we ship it?
How do we deploy to production and release to our customers?
Who do we need to involve?
- How do we monitor it?
How do we monitor what we have delivered?
How do we feed insights back into the product backlog?
How do we deal with alerts?
- How do we maintain it?
How do we support the product and maintain its technical health?
Example activities for a product delivery team
Step 4: Brainstorm Expectations
This is the core of the session, and will take the majority of the time. The key is to brainstorm what is expected of the role for each of the activity stages. Use the questions identified in the previous step to prompt conversation and generate discussion. I use a couple of additional clarifying points to help facilitate the discussion for each expectation we identify:
What is the underlying purpose of the expectation?
When and how often should we do this?
Example expectations for a product delivery team
Step 5: Get agreement
It’s one thing to gather the expectations, but you’ll need to get approval from the group that they find them reasonable and will sign up to them. I use a consent based voting approach, with the proposal being the expectations map that they would sign up for for a month, after which we will have targeted Retrospective to check in and review. This is a living document after all, that will evolve over time.
I’ve found this a really valuable, inclusive approach to identifying expectations between roles. Give it a try and let me know how you get on!
Categories: Agile Coaching.