Effective Sprint Planning - Five Things to Consider
Anyone who knows me, knows my general dislike about scrum methodologies. But Scrum is everywhere and some are even following it as a religion. Well, if we are continuing this cultish ideology, let me help a bit. Here are the things that I think teams should consider right before committing to a sprint. Take 5-10 mins at the end of every sprint planning to reflect on the following questions. You may want to adjust your sprint commitments if your answer is mostly no. This has helped the teams that I have led in past to commit to an arbitrary time boundary of 2-3 weeks that Scrum recommends and I passionately disagree with.
Are we doing the most important work?
Someone who is directly responsible, perhaps an engineering manager or a product manager, should look at the sprint tickets and check again that the most important work is taking the priority. Don't carry over tickets from the previous sprint just because they were in the previous sprint or have been worked on partially.
Is the work parallelizable?
This should be a team exercise to ensure that most tickets can be worked in parallel. If you have 5 engineers on the team, you would want tickets that all 5 can work in parallel on day 1 or they are committed to pair/mob program. This question will also guide you in prioritizing blocking tickets higher on the sprint board.
Are we balancing features, tech debt, and bugs?
A healthy sprint commitment should include features, tech debt and bugs tickets. Negotiate if you are being told to only prioritize features. This is how you accumulate tech debt and bugs overtime. 10-20% of sprint capacity is a good number to start with. Decreases/increase this bucket depending on how healthy your products are.
Can we demo our progress at the end of the sprint?
Are you demoing your progress to your users every sprint? If not, why not? Demos can target your fellow engineers not just the users and the stakeholders. You don't have to demo the most shiny thing every 2 weeks. Work always take longer than that in the real world. There is value in demoing the progress even if you don't have the finished product. Build your iterative story every sprint.
Are we using data and instincts for sprint commitment?
Use your sprint-over-sprint median velocity to make the commitment. Also, adjust the velocity to account for variables, such as, if several of the team members are going to be out, a new engineer is joining the team, several vague tickets are in the sprint, several "easy" repetitive tickets are in the sprint etc. Try to push for committing to a higher number, 5% to start perhaps, to see what threshold you could reach. Adjusting commitment like this is a controversial topic for purists scrum masters. I believe that humans generally don't want to lose. Set ambitious yet realistic goals. You don't want your engineers to feel defeated at the end of every sprint.
Holler at me if you have other tips for effective sprint planning or if you found this article useful.