Agile workflow: Sprint planning
This post is by Ben Zimmerman, a member of SpiderOak’s Engineering team.
In my last post I talked about planning features at a high level. This time I’ll talk about how we plan for an individual sprint. The goal with sprint planning is to accurately plan what you can accomplish while working at a sustainable pace.
For sprint planning we use a point system based on the fibonacci sequence. 1, 2, 3, 5, 8, 13, 21. The idea is that as estimates get larger uncertainty grows so the gaps between estimates grow. Each point is roughly one days worth of work.
Most tasks should be broken down until the sub tasks are five points or less. It’s very difficult to accurately estimate something that’s more than a few days of work.
Eight points means a task is more than one week of work, but probably less than three weeks. We recently assigned eight points to porting a fairly large app to python 3. With that sort of task we knew it probably wasn’t huge, but there was no real way to break it into smaller tasks.
13 points means we have a reasonable idea of what needs to be done, but probably won’t finish in a single sprint. This should only be used for tasks that can’t be broken into smaller pieces.
21 points is used when we have no idea how long something will take. This usually means that more investigation is required. Examples would be starting to use a new language or framework, or a difficult bug that we haven’t been able to reproduce.
We work in three week sprints with approximately 10 points per developer, so we’re scheduling about 3 points per week. The missing two points are to account for the inevitable distractions we’ll run into. I have one day a week where I use the morning for planning and I have three meetings in the afternoon. I intentionally pack most of my meetings into one day so I have more large blocks of time to work on other days. The other extra day is there for emergencies, assisting other developers, and inaccurate estimates.
With this schedule I’m usually able to complete all of my tasks. Often, one of my tasks will end up being bigger than expected and fill most of my cushion. When everything goes smoothly I can finish by Wednesday or Thursday of the final week of the sprint. I’ll then use the extra time for long term planning, refactoring, or I’ll pick up an extra ticket.
You should take your circumstances into account when assigning points. I work remotely and we’re pretty good at minimizing meetings so most of my time is available for development. If you have meetings every day it may only be realistic to take one or two points per week. Hopefully if you need to do that it’ll highlight how many distractions you have and you can push to reduce them.
The goal of planning is to accurately estimate what will be accomplished. It’s not to push people to get more done. Therefore, it’s important to take into account anything that’ll take away from development time. For example, we recently had the primary support person for one of our products leave. I scheduled slightly less points for the next two sprints so I could be available to answer questions and train his replacement. If you don’t take things like this into account in your planning, people will either neglect important tasks or be overwhelmed by the unreasonable workload.
Originally published at engineering.spideroak.com on September 12, 2018.