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.