Practical Guide: The 7Ps Framework

Meeting

Meeting” by John Benson is licensed under CC BY 2.0 

In this blog post I introduce the 7Ps framework from the book Gamestorming, which is fundamental for me in regards of planning successful meetings.

James Macanufo’s 7Ps framework is a tool for planning and preparing meetings. I use it as a checklist each time I am inviting someone to a meeting. So here are the 7Ps that you should pay attention before sending out your next meeting invitation:

Purpose

Why are we having this meeting? – Giving people a purpose to meet is most fundamental. Explain your participants why you are having this meeting and if you can’t come up with a purpose don’t have the meeting.

Product

What specific artifact will we produce out of this meeting? – Think of what you want to produce as an output of the meeting and communicate it to your participants. Depending on the desired outcome people will set their expectations.

People

Who needs to be there and what role will they play? – Depending on the purpose and the desired outcome select the right people for your invitation. One strategy is to think of the questions that need to be answered first and than select the right people who might have answers to it.

Process

What agenda will these people use to create the product? – You can either define the agenda on your own or co-design the agenda with the participants in order to get more perspectives on the process.

Pitfalls

What are the risks in this meeting and how will we address them? – Risks can be laptops or smartphones that distract participants, lousy facilities (e.g. beamers, sound equipment, flip charts,…), a large number of participants, or personal issues between participants. Create rules (e.g. “no laptops/smartphones”) and check all possible pitfalls upfront to minimize bad surprises.

Preparation

What would be useful to do in advance? – Tell your participants what they must prepare for the meeting (e.g. if you expect them to have ideas or concepts prepared tell them your concrete expectations) and prepare yourself carefully (e.g. hand-outs, slides, room, speech,…).

Practical Concerns

These are the logistics of the meeting – Where and when is the meeting? Does the room have sufficient equipment (e.g. video calling equipment for a remote session)? When is the best time for the meeting? (e.g. after lunch people are often less energized, time zone constraints,…) Who is bringing lunch?

James Macanufo provides the following strategies on applying the framework:

  • Each of the 7Ps can influence or change one of the others, and developing a good plan will take this into account
  • Get others involved in the design of the meeting
  • Revisit the question “Why are we having this meeting?” for recurring meetings regularly
  • Make the 7Ps visible during the meeting
  • Have a plan and expect it to change

How do you plan your meetings?

Why You Should Define Reference User Stories

If your organization is new to Agile one of the things you might struggle is the shift from traditional to agile estimation. I have seen a lot of inexperienced agile teams struggling with the nature of story points and relative sizing. Often a lack of trust in their own estimates, which led to poor planning, was the consequence. A simple tool, called reference user stories, helped each of these teams to overcome these difficulties.

If you haven’t defined reference stories with your team yet, consider well-defined, well-sized, not too domain specific user story from your past sprint(s) as candidates. Ideally you want to have reference stories of different size (e.g. 1, 2, 3, 5, 8 and 13 story points). Alternatively you can define artificial user stories that will serve as your references. Create a table of your reference stories, like the one below, and use it in your backlog refinement meetings. Feel free to add or exchange reference stories later if you feel the need later.

Size User Story
1 Story A: As a user I want to see my user name on the page so that I know that I am logged in with the right user.
2 Story B: As a user I want to write a comment to a topic so that I can express my opinion to the author.
3 Story C: As an administrator I want to block users for the forum so that I can prevent them from spamming.
5 Story D: As a user I want to register for the website so that I can use their premium services.
8 Story E: As a system administrator I want to migrate data from database A to database B via an automated script so that I can handle the amount of data.
13 Story F: As a user I want to purchase a product via the online shop so that the article is delivered to my home.

According to my experience reference user stories have the following main benefits for agile teams:

  • Supporting relative estimation: A user story (e.g. Story X) is relatively sized to the defined reference stories (e.g. Story A, B, C, D, E, F), which helps to focus on relative estimates (e.g. story X is bigger than story B, but smaller than story D) instead of absolute figures (e.g. story B will take 40 hours of work).
  • Increase accuracy of estimates: Relative estimates are more accurate, because our brain is naturally better at relative sizing then in absolute estimation. Defined reference stories also keep a stable reference and therefore reduce variability in the estimates.
  • Normalization of story points: Defining, sharing and using reference stories among multiple teams, normalizes their view on story points. With normalized story points we can calculate velocities for multi-team projects by just summing up the team velocities. (WARNING: Never abuse normalized velocities for team performance measures!)