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.
- 1 point: Small or basic text change. Updating configuration, fixing a typo or cognitively simple bug.
- 2 points: Task with light complexity. Some portions of code have to change, be debugged, tested.
- 3 points: Some complexity, will take time to implement. Potentially a few days' worth of work. May require front- and back-end work, or back-end and database work.
- 5 points: Half a sprint's worth of more complicated work. Full-on feature implementation for example.
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:
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.