Some Nascent Thoughts on Facilitating Sprint Planning

--work in progress, comments welcome!-- I guess the question to start with is "who facilitates sprint planning?" Is it the Business Analyst (BA)? The product owner (PO)? The team lead (TL)? My initial thought is that it doesn't matter too much who facilitates. Anyone can facilitate the sprint planning. Even one of the developers or designers. So what's important to cover in sprint planning?

I think a good place to start is to look at the current sprint (the one that just ended) and make sure everything on the board is up to date. Then close the sprint and carry over all unfinished work to the new sprint. A good second step is to look at the team's velocity. Where I work (at Trainline), we use JIRA, which is an extremely ubiquitous project management tool in the software industry. And it has lots of little charts you can look at, one of them being sprint velocity. The first thing to note when looking at velocity: is it relatively stable? If it is, then I think using the average number of points per sprint as a starting point for the next sprint is a good idea. If the velocity is not stable, then maybe take a moment to consider why that is. Is this a new team? Were there lots of holidays taken during the last few sprints or other types of disruptions? Is there a problem with the way the team is pointing stories? It could be ideal to go with the lowest number of points per sprint in this case. Or maybe still with the average. It's up to the team. Once we've decided on a starting point for the number of points we want to pull in to the next sprint, we need to ask ourselves questions like:

• Does anyone on the team have time off planned during this sprint?

• Is anyone on the team coming back from holiday?

• Are there national holidays during this sprint?

• Is anyone new joining the team?

• Is there anyone new on the team?

• Is anyone leaving the team?

• Are there any company events planned during this sprint?

• Does the team have any other responsibilities to consider during this sprint (like being on call or managing a release)?

• Are there any actions that came out of the sprint retro that we want to include in the next sprint?

And, based on the answers to those questions, we should adjust the number of points we plan to commit to for this sprint. Here is how I would adjust:

Scenario	Adjustment	Reasoning
One or more developers have holiday planned	Decrease	obvious
The designer, PO, BA, or TL has holiday planned	No change?
One or more developers is coming back from holiday	Increase!	But don't go too crazy! They may need a day or two to catch up on Slack and email. And any training or company admin they might have missed while away.
The designer, PO, BA, or TL is coming back from holiday	No change
There is a national holiday	Decrease	obvious
There will be a new developer joining during the sprint	Decrease big time	It will take several days for this new developer to get set up. And then, they should probably not work on time-sensitive sprint work first thing. It'd be better to have them work on some old tech debt (or new tech debt!). And at least one dev should be designated for pairing with them for the whole sprint. So that means we are down 1 dev this sprint.
There will be a new designer, PO, or BA joining this sprint	No change
There will be a new TL joining this sprint	I have no idea. I assume decrease? But big decrease or small decrease?
There is a new developer on the team (but they joined in a previous sprint)	decrease	It takes a village! The team should all still be involved in helping this person with onboarding!
There is a new designer, PO, BA, or TL on the team (but they joined in a previous sprint).	I don't know
A developer is leaving the team	decrease big time	That person will need to be wrapping up any loose ends! And saying their good-byes. And maybe having exit interviews. They might be knowledge dumping (which might require the other devs on the team to participate).
A designer, PO, or BA is leaving the team.	decrease?
The TL is leaving the team.	decrease
There is a company day planned during the sprint. Or a conference or an offsite. Or people are visiting from another office.	decrease
The team has another responsibility this sprint, such as being on-call or managing a release	decrease	Over time, it'd be good to track these sprints somewhere so that you could figure out the average adjustment for a sprint like this.
There are some actions that came out of the retro and time and resources need to be allotted to them during this sprint.	decrease

If we have well-written user stories and we have been grooming the backlog, the next step should be trivial: we look at the number of points we are willing to commit to, and we take as many tasks off the top of our list as we can, without going over that number of points. In reality, it's not usually this simple. Often there are stories that cannot be pulled into the sprint together because they cannot be worked on in parallel. So that is one thing to watch out for. Another thing that a team must have in order to have a successful sprint planning is a "Definition of Ready". Additionally - how do you "point" spikes? The teams I've been on tend to time-box them. So that has to be taken into account as well in regards to the number of points being pulled in to the sprint.