Useful Sprint Planning from a Certified Scrum Master

This is a small collection of sprint planning/story points allocation tips and tricks that I use at work. They pretty much all come from our in-house certified "Scrum Master". He's got much better experience than I do with building a real working backlog of stories and planning sprints based on those stories. That being said, any opinions here are my own and I don't speak on his behalf.

Points as a Measure of Work

In my understanding, points are approximate measures of the amount of work required to complete a given story or task. I do not think points correlate to an exact measure of time. I use them to determine the size of a task in relation to another task. For example, a simple-looking task may be allocated 1 point. In reality this 1 point may take 1 minute or 1 hour to complete. The time it takes is less important than the ratio of time it takes in comparison to a second given task. Say the second task appears to take twice as much time as the first (however much time that may be). The second task would therefore get 2 points.

Some teams have a special system for incrementing points. Our team uses the Fibonacci sequence of numbers. So the smallest amount that can be allocated to a story is 1. Then it goes 2, 3, 5, 8, and so on and so forth. If a single story is going to use up 8 points, you should probably take a look at breaking it up into smaller tasks. A single story shouldn't take up almost half of your allocated work for a sprint.

How Much is Enough?

Our team aims for 10 points per 2-week per sprint. Simple enough for me, but the hard part is determining how many points to allocate to a given task.

One thing I could never figure out is what the recommended starting position for 1 point looks like. I'm sure this is something that comes from experience, and our Scrum Master helped us out with that.

Prioritizing Work

I do not see points as indicative of the importance or priority of a task or story. Just because one task will take longer to complete than another does not mean it's more or less important to me. There should be another method of gauging which stories should be taken off the backlog first. For example, one story might depend on another. One might relate to core functionality that a stakeholder has asked for. Another task might be required to make code build because it solves some major problem!

To communicate how "important" a task is, every story we have is prioritized something like this:

  1. Critical
  2. Blocker
  3. Highest
  4. High
  5. Medium
  6. Low
  7. Lowest

Tasks that align with some long-term project that management is waiting on are tagged "Highest". Stories that prevent lots of other stories from being completed may be labeled "Blocker".

Sprint Planning/Backlog Refinement

With all that in mind, at the start of the sprint I now take about 10 points worth of priority work off of the backlog. I'll work through it the whole sprint through and then, ideally, it'll all be complete by the end of the sprint. If I bit off more than I could chew and the sprint ends before I'm finished, the incomplete work rolls over to the next sprint and is the first to be completed. If I find I've finished everything I had to work on and there are still a couple of days left in the sprint, I'll take one or two small items off the backlog and work on those.

Tools to Get the Job Done

Our team uses Jira at work, and I know some folks love it so much they've paid for a personal license. It's a bit overkill for my personal projects, so I've been using Nextcloud's Deck plugin. This is an okay solution but it doesn't integrate very well with source code repositories (although it can tie into a Nextcloud "project", or a collection of related files open to a team). I'm spinning up a Gitea server to replace my git-web server soon and this is one of the reasons for that. Gitea has a GitHub-style issue tracker where you can create issues of various kinds, assign them to users, reference commits to the source, and create a Kanban-style board of issues that are on the backlog, to-do, in-progress, or done.

I'm still learning how to keep to a Scrum-like process of some kind, because I do see the benefit of using such a system, especially in a team. I'm definitely not an expert though so some of what I've got here may change over time. Right now it's working well and that's good enough for me.