Participants of sprint planning meeting - Is it essential to involve part-time team members

Question

I'm currently in the process of getting my team in a position to start using Scrum and Sprints within the next couple of weeks - I intend on taking on the role of Scrum Master as long as everyone on my team agrees that makes sense. One of the members of my team only works part time, and I've been getting varying feedback as to the length and purpose of a sprint planning meeting. One suggestion I had was breaking the sprint planning meeting across more than one day, partly so that the part time person is still able to be fully engaged during the sprint plan. However, this takes more of the "productive" time away from the part time individual. This also assumes that sprint planning is something that takes "about a day" to accomplish, given a two week sprint.

So, should I include my part time person in our sprint planning sessions? Or, is it my job to serve as his representative, and make sure that even though he's not present for the sprint planning, his abilities and needs are still met?

Answer 1

I think there's another point to this question that isn't covered yet and that is:

What should actually be covered in a sprint planning?

(or why does it have to take a lot of time at all?)

Short answer: In a sprint planning you should only be planning the sprint.

What that means:

• Looking at your tasks and stories
• Quick estimation (if you do estimates; e.g. planning poker)
  • emphasis on quick
  • if discussions get out of hand that means the story wasn't 'ready' in the first place
  • re-estimate stories that have been estimated before but are not yet done
• reaching consensus about the amount of points/stories to put into the sprint
• verbal commitment from the whole team

So why does this take long?

Because people do way too much in a sprint planning. Amongst to worst planning killers are in no particular order: task breakdown, task estimation, story estimation, getting stories 'ready' to be planned in the first place, discussing features, figuring out who's available during the sprint in the first place. I could go on. And so could the sprint planning.

Don't do these things in a sprint planning. They are not planning, they are preparation and you prepare beforehand. Because knowing is half the battle.

I had the best results pulling these killers out of the planning this way:

• backlog-grooming sessions as needed
  • with: scrum master, PO and some, not necessarily all team members (rotate if you don't want to tie up the whole team)
  • doing: reviews of the stories in the back-log, stating/discussing open points and priority
  • to: get enough stories 'ready', i.e. get enough information to do a task breakdown
• task break-down sessions
  • with: scrum master, some or all team members
    • recently I had this done by pairs and then in the next session checked by a different pair
  • doing: a list of tasks necessary to accomplish the story, in a detail level your team is comfortable with; alternatively noting open questions and handing the story back to the backlog for grooming
  • to: get at least a bit more than - comfortably twice the amount of - roughly what would usually be done in one sprint, so that the sprint can be planned with some head room for rejected stories

NB: I mentioned 'ready' a couple times. This relates to the definition of done (which defines when something counts as delivered) but covers the other end of the process, planning your sprint, defining when a story is ready to be broken into tasks and estimated. For this, like for the DoD, you and your team need to figure out what they need and are comfortable with.

I want to give you one example of mine though:

• All open questions are addressed
• The priority of the story in the backlog is clear
• The stake-holders are committed to being available for questions during the sprint
• There are no incremental steps (or smaller stories) that this story can be broken down into that individually still create value

Bottom line

If you get a routine going with your steps split out like this, your planning won't take a whole lot of time (as little as about two hours for a two week sprint) and each of the steps can be flexibly placed throughout the sprint to make it possible even for your part-timers to attend.

Answer 2

TL;DR

Your part-time people need to be present for Sprint Planning. Specifically:

• Do NOT:
  • act as a team member's proxy during essential framework meetings.
  • attempt to circumvent framework-mandated meetings such as Sprint Planning or the Daily Stand-Up to accommodate resource constraints.
• Instead, you should:
  • accept that part-timers create additional process overhead, and avoid the 100% utilization fallacy.
  • adapt your sprint schedule and velocity expectations to fit the team you currently have, rather than the team or project resources you wish you had.

Who Should Attend Sprint Planning

Everyone on the Scrum team must participate in Sprint Planning. While it's important for all team members to participate in the estimation of Product Backlog items, it is critical that all task-performers be active participants in decomposing stories for the Sprint Backlog.

Why Attendance at Sprint Planning is Important

Accurate estimates are based on what team members know (or don't know) about a story. Unless you are planning to perform the tasks yourself, it doesn't matter whether you think a task is easy, hard, or in-between because you aren't the one doing the work.

When the whole team estimates, you have a broader consensus of what's involved and how much work is needed. In addition, in a team-based approach more than one person contributes to each story, and each person who will work on a story-related task needs to:

• have input into what they need from others to complete each task, and
• be able to estimate (and communicate with the rest of the team about) when and how hand-offs will occur.

These things are essential for a self-organizing team to be able to coordinate with one another during a sprint. Doing this by proxy is defeats the self-organizing principles that Scrum is meant to harness.

In the case of part-time resources, this is even more important because part-timers have more cognitive and process overhead than full-time people, and will need to coordinate more closely with the rest of the team to ensure successful hand-offs. You will make matters worse, not better, by dis-integrating your part-timers from the rest of the team in the name of efficiency.

How Long Sprint Planning Should Take

This will vary by team and project, and you will need to adapt the time-boxes for your specific needs. For new teams, I recommend starting with one full day for Sprint Planning each sprint, where:

• 4 hours are time-boxed for defining the Sprint Goal, and then estimating, negotiating, and accepting stories from the Product Backlog to fulfill that goal.
• 4 hours are time-boxed for decomposing stories into tasks and dependencies for the Sprint Backlog.

Experienced teams may be able to cut this time down, especially with the effective use of Backlog Grooming, but trying to cut it down "just because" is a false economy. After all, Sprint Planning is where a significant portion of the team's analysis and design is performed, so allocating a mere 10% of your sprint to ensure that you're building the right things in a sustainable way is much more important than shaving a few man-hours from your budget.

When You Should Hold Sprint Planning

That's up to the team, but it should be on a fixed schedule. Since you're trying to incorporate part-time people, the team should choose a day that's convenient for as many people as possible, and the part-timers will need to be flexible, too.

Sprints can start on any day of the week you choose, so there's nothing wrong with starting your sprints on a Thursday if that's what works best for your team. What's essential is that the schedule should be both predictable and sustainable.

You can also split the Product Backlog and Sprint Backlog sessions across days, but this leads to additional process overhead. This may be necessary if you have part-time or matrixed resources, but your team and your organization need to acknowledge that this will create additional drag on your process. TANSTAAFL; it's simply the price the team must pay if it can't ensure dedicated resources, and the organization should treat it as the cost of doing business rather than wishing it into the cornfield.

Answer 3

Include all team members in sprint planning

The basic tenet of Agile/Scrum is that there should be direct communication between the Product Owner and the team doing the work. Also, the members who will be doing the work should make a team commitment to completing what they signed up for. So, you should try to include your part time person in your sprint planning sessions.

However, you didn't say what your role is. Looks like you are the ScrumMaster. As ScrumMaster I have coordinated with part time resources while the sprint is in progress.

There is no hard rule that sprint planning should take a day for a two week sprint. If you are able to do effective planning, without cutting short essential activities, it is OK to make it shorter.

Answer 4

I recommend taking a look at the Scrum Guide available through Scrum.org (Ken Schwaber's company) - it pretty much lays things out and is written/maintained by the codifiers of the framework (Jeff Sutherland and Schwaber).

All members of the Scrum Team should be there:

• Scrum Master (facilitator who ensures the Scrum process is being followed),
• Product Owner (curator of the product backlog), and
• All team members (this would include the part-time person).

Only the people actually doing the work should be acting on their behalf.

The Sprint planning meeting is a one time meeting - no longer than 8 hours in length for a 30 day sprint - proportionally shorter based on the length of the sprint (so a 15 day sprint would have a Sprint Planning meeting of no longer than 4 hours).

It is not recommended spreading the meeting over multiple days - even just to include the part-time person. A couple of options would be:

1. Find a day/time when (s)he will be there and adjust your sprint lengths to accommodate for him/her; or,
2. See if the team (including the part-time person) is comfortable with other members being his/her proxy.

But, if your team cannot determine what can be done within a sprint in a single planning meeting there is something going on that should be examined. For example, the sprint duration may be too long/short, the product backlog items may not be defined well enough to be estimated properly, and so on. With a two week sprint, you're looking at roughly a 4 hour planning meeting - maximum (most time-boxes in Scrum are "not-to-exceed" durations and proportional based on the length of the sprint - except the daily Scrum meeting of 15 minutes or less).

Hope that helps. Let me know if you would like any clarification.