3

What should we do if the PO is unable to attend the Sprint Planning meeting? Is there a workaround for it?

  • Ummm.... the team should take a week's vacation. :-) (Sorry, can't resist.) – Danny Schoemann Nov 24 '19 at 10:00
3

The team goes on with the sprint planning without the PO.

During Sprint Planning, the team assesses what can be accomplish during that Sprint. You select items from the top of the backlog and you work on those. Sure, the sprint goal might be a little bit fuzzy, the PO might not be there to answer questions for the best understanding of what's needed, and the team might have to extrapolate some things, but if you have a proper Scrum team you can work without the PO until they get better.

When I say a proper Scrum team, I mainly refer to two things:

  • the team is self-organized, so everyone understands what's needed and how they can build it
  • you properly did the refinement activity, so you don't have a big surprise at the sprint planning.

If you can check these two items then it means that the product backlog is properly prioritized, the backlog items were discussed, properly sized, estimated, there is acceptance criteria for them, etc. You don't have the PO in the sprint planning to help but you basically know what's coming your way.

Maybe you can ask someone with whom the PO works closely for business advice, if such a person exists. If the PO is available by email or phone, you might try to contact them. But given what I mentioned, the team should be able to work without the PO for a while.

2

The Two Core Options

The Scrum Team has two basic options:

  1. The rest of the team can proceed with Sprint Planning using the current state of the Product Backlog.

    The Product Backlog should always be in an actionable state. While it's best if the Product Owner (PO) is present in order to help the team articulate the Sprint Goal, clarify any ambiguous items or scope, and to make on-the-fly adjustments to the Product Backlog, planning can proceed without the Product Owner.

    The Product Owner and the rest of the team should also acknowledge the limited risk that needs to be accepted in order to proceed. There is scope and planning risk to the current Sprint, and schedule risk to the overall project, but the risk is generally limited because of the time boxing inherent in the Scrum framework.

    Upon return, the Product Owner can always cancel a Sprint and return to Sprint Planning as a visible cost to the project if necessary.

  2. The Scrum Team can collectively agree to reduce the capacity of the current Sprint.

    Whether it's the Product Owner or not, sometimes key people are sick, go on vacation, or are otherwise not available at all times. When this happens, the team needs to reduce the planned capacity of the current Sprint by an appropriate fudge factor in order to maintain an effective time box.

    For example, if the Sprint Planning session must be postponed by a day or two, this will result in a shorted Sprint. In a one- or two-week Sprint, the Development Team may need to reduce the work they pull into the Sprint by around 20% or so to account for the late start.

Neither approach is perfect, and both entail some limited risk that is ideally bounded by the time box for the current Sprint. On a long-running project, either approach can work. The Scrum Team just needs to agree on what's best for them and for the project.

Risk-Mitigating Practices

You can't eliminate all risk of having key personnel absent at framework events, but you can minimize the effects. Some practices that may help should be discussed at a Sprint Retrospective, and incorporated into your process as appropriate. Examples include:

  1. Leverage Backlog Refinement events to ensure that the absence of the Product Owner isn't a complete blocker for Sprint Planning.
  2. Have the Product Owner attend Sprint Planning via audio or video conference if they are too sick to be physically present.
  3. Keep a number of "evergreen" items or Sprint Goals on the Product Backlog that can be pulled into a Sprint when necessary. Professional development, education/training, and story spikes for tool chain enhancements are common examples.
  4. Increased collaboration so that the Product Owner routinely shares the product vision with an empowered, self-organizing team.
  5. Increased collaboration with stakeholders/users, so that backlog items can be clarified directly rather than being solely dependent on the Product Owner.

In short, your goal isn't to keep everyone busy 100% of the time. Your goal should be a sustainable process with sufficient slack to handle minor perturbations over the lifespan of the project. Good process operates as a smoothing function over time, not as a whip to force people to work harder or perform busy-work because of entirely-predictable variances.

Attendance and per-Sprint capacity will vary. The efficacy of the framework, when properly applied, does not.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.