Planning Session

Planning session

1. Intro

If you think about a Product Requirement Document (PRD) as answering the What and the Why. The planning session heavily informs the How. I have used this at Sphere and Prolific with some degree of success.

2. Requirements

  • The session benefits from a PRD. In its absence, a team can use a set of user stories.
  • The session is attended by the team’s engineers (usually 2-6). If the team is more than 6 individuals, is preferable to have a function’s representative (e.g. backend, web, iOS, Android). For work that is heavily in UI, having a designer in the session will help. A PM doesn’t need to attend the session. This is specially true if the work is very technical, or backend oriented. They should read the outcome of the session.
  • Individuals attending the meeting have read the PRD, beforehand.

3. Goal

The main goal of the planning session is to clarify unknowns and align the team. Throughout the session (usually 90 minutes), the team goes through the PRD’s spec. Each item in the spec is broken down, discussed and estimated. By the end of the session, it should be straightforward for engineers to create their own tickets. PMs shouldn’t write tickets, that’s an engineer responsibility.

4. Example

Instead of providing a theoretical approach, I will explain it with a simple feature.

Our cookbook iOS app allows users to search and view recipes. Currently only our in-house chefs can add recipes. We do this in a cumbersome way, via our admin back-office. For V2 we want to allow any user to add their own recipes to the app and be available for everyone.

User stories:

  • As a user I would like to add my own recipe so everyone has access to it.
  • As a user I can edit and delete my own recipe.
  • As a user I have access to all my recipes under “My Profile”.

The following is a potential approach to the problem:

Backend:

  • Assume we can use the service we already have for our in-house chefs.
    • Check if the existing service would work for users without admin rights.
    • Check that a regular user can create, edit and delete recipes.
  • We need a new service to allow users to fetch their own recipes. Something like user/id/recipes should do it.
    • Make sure we have pagination, so we don’t return the whole list.

iOS:

  • A whole new screen where the recipe is created is needed.
    • There are a couple of new UI components we don’t have, so they need to be created:
      • A picker for the recipe’s header picture.
      • An horizontal image gallery to show the recipe’s preparation pictures.
        • Tapping the image displays it fullscreen.
      • A slider to set the time for each step of the recipe.
    • Make sure we can reuse this screen for editing and deleting.
    • By tapping “Confirm” at the bottom, a new recipe is created.
    • When creating the recipe, by tapping “Confirm” at the bottom, we need to make sure that if something goes wrong we show a message to the user.
    • The delete button at the top is only shown when we are editing the recipe, not when we are creating it.
      • If deleting fails, make sure we display an alert to the user.
    • In edit mode, the “Confirm” copy changes to “Update”.
      • If editing fails, make sure we display an alert to the user.
  • There’s a new top button, to add the recipe:
    • This button is only visible from the recipes feed screen.
    • We need an asset to represent button.
  • In the profile screen we now have a button to navigate to the user’s recipes.
    • A new screen where all the user’s recipes live is needed.
      • If the user has no recipes, show a blank screen with a plus button to add a new recipe.
      • If fetching the recipes fails, show a placeholder failure as a screen, with a retry, instead of an alert.
    • Swipe-to-delete a recipe is possible.
    • We only fetch 15 recipes at the time, if the user reaches the bottom, 15 more recipes are loaded.
      • If it fails, display a retry button at the bottom, after the existing loaded items.

Once the team agrees with the flow and interaction between backend and frontend, we can jump to estimation. For this part of the session, engineers provide three values for each item: pessimistic, realistic and optimistic. These are defined in engineer/hour, but feel free to pick another unit of measurement.

With these values in hand, we know that at worst, it might take roughly take 24 days per engineer for the iOS team and 6 days for the backend team. Since we can parallelise the backend and frontend work, at best, we might deliver the whole feature in 12 days.

We can further improve our estimation. Specially with the massive 40h for the Create Recipe screen and the Recipes List. The general rule is: if, at worst, a task takes more than 2 days, break it down.

5. Guidelines

The following is a set of guidelines and advise:

  1. If engineers are struggling with a number, it’s a sign that the task is unclear. It can either be because it’s too big, or the item is not well understood. Don’t block the session if you feel that coming up with a number will take a long time. Engineers can find an answer at a later point (either async, or sync). Once they have a better sense, they should update the planning document.
  2. Depending on the seniority on the team, you might need to be more hands-on during the session. This means helping with the estimations and challenging assumptions. For the last point: don’t shy away from digging further.
  3. It’s likely that during the session you will uncover edge-cases that were not covered in the PRD. Update the PRD and inform the PM.
  4. The session shouldn’t take more than two hours. Don’t be pedantic about exact numbers. If by the end of the session the team feels more confident, it’s already a success.
  5. If you don’t feel comfortable with time (e.g. hours), you can go with complexity instead (e.g. Fibonacci numbers). If you don’t feel comfortable with either, that’s ok. The goal is to have a sense that the problem is well understood and that the team has a way forward.