Yes, you should attend sprint planning
How this critical meeting can offset a software team’s productivity
Picture this.
Every two weeks, during a three hour long sprint planning meeting, software engineers (SDEs) go through an exhaustive list of all things that needs done, votes for Fibonacci points for each story, breaks down larger stories to smaller tasks, assigns stories and tasks to different people. Managers and technical program managers (TPMs) do not attend these meetings to delegate ownership to the SDEs.
If you are screaming on the inside by now, good for you, you should probably stop reading. To the rest of you, this may seem all too familiar, and you may be wondering, what’s wrong with this picture?
If you can spend less time, don’t spend more time
The first thing that should jump out at you is the fact that this recurring meeting lasts three hours. SDEs are expensive, at an median salary of $220k/yr, with a typical two pizza team of six SDEs, this is a meeting that would cost roughly $1903 per meeting, and $49.5k/yr! That’s enough to fly everyone to Hawaii, sipping Mai Tais on a beach for a week, pay for hotel and airfare and still have left over for beer in the team fridge (if you budget correctly).
An efficient sprint planning meeting should last one hour at most, and consists primarily of discussions of technical strategy and decision making.
If you spend time, it has to be worth while
The second issue with this process is the output at the end of the day. Sprint planning is supposed to produce the blueprint for the team’s execution for the next two weeks. Everyone should feel confident in the decisions they’ve made in the meeting, and the relative priorities of tasks are clear as day. Teams will often leverage the priorities to stack rank their deliverables, and then decide to only work on a subset of available work, with the work that’s de-prioritized being called “below the line”. With this desired output in mind, this particular team spent almost the entirety of the meeting voting on points for stories.
Don’t do fibonacci numbers
Just my opinion, ask yourself these questions, before you take my word for it.
- If it’s not a Fibonacci number, can you not start to work on it?
- Have you ever been on a team that has been able to keep these estimates accurate?
- It probably takes longer to vote and point 50 different things than it takes to just do one thing.
A much better system in my experience has been, everything is somewhat equally pointed, to a point where there isn’t a need to point anything differently. Doing this correctly can take a bit of practice, but at the end of day you can deprecate the scrum poker cards all together.
Let software engineers write code
Here’s what a day in the life of a SDE look like.
The more contiguous block of time you can give to engineers the better. That means minimizing process, point the team in the right direction, and unleash productivity. If you interrupt the day with a three-hour planning block, that will surely drain any productivity out of even the best engineers.
You (the manager) should attend sprint planning
The last issue and the most critical issue for this situation, is that no managers were present for this planning meeting. It is the job of the manager to plan and lead execution of the plan. For a software team, the mechanism to do both is the sprint planning meeting. In the event where the manager is too high level, and has effectively delegated responsibility to another frontline manager, the responsibility to lead the planning meeting would befall on to another manager. In any circumstance, a manager is supposed to be present at the planning meeting to make or help make a few decisions, e.g. Should we do A instead of B? Or If we do C, then we have to slip D milestone by some days. Or let’s prioritize metrics over functionality or vice versa. Or literally anything at all.
Come to sprint planning with a list of predefined stories for debate. These should include things in flight, things to start, and backlog or items being punted. The outcome should be three well refined lists, each story with an owner.
There are times when SDEs should argue with each other, let it be design patterns, simplifications, or picking a lunch place. Team priorities for the next two weeks should never be unclear, and it is the manager’s job to be present at sprint planning, to reinforce the team priorities, and to inspire confidence and move conversations along, so SDEs can get back to coding. (that’s actually what you pay SDEs for)
So, yes, if you are on a software team, you should attend sprint planning. And if your sprint planning doesn’t measure up to what you would expect, you should change it.
