Useful Sprint Planning from a Certified Scrum Master

<h1>Useful Sprint Planning from a Certified Scrum Master</h1>


<p class="description">
	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.
</p>

<h2>Points as a Measure of Work</h2>

<p>
	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.
</p>

<p>
	Some teams have a special system for incrementing points. Our team uses
	the
	<a href="https://en.wikipedia.org/wiki/Fibonacci#Fibonacci_sequence">Fibonacci sequence of numbers</a>. 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.
</p>

<h2>How Much is Enough?</h2>
<p>
	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.
</p>

<p>
	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.
</p>

<ul>
	<li>
		1 point: Small or basic text change. Updating configuration, fixing a
		typo or cognitively simple bug.
	</li>
	<li>
		2 points: Task with light complexity. Some portions of code have to
		change, be debugged, tested.
	</li>
	<li>
		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.
	</li>
	<li>
		5 points: Half a sprint's worth of more complicated work. Full-on
		feature implementation for example.
	</li>
</ul>

<h2>Prioritizing Work</h2>

<p>
	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!
</p>

<p>
	To communicate how "important" a task is, every story we have is
	prioritized something like this:
</p>
<ol>
	<li>Critical</li>
	<li>Blocker</li>
	<li>Highest</li>
	<li>High</li>
	<li>Medium</li>
	<li>Low</li>
	<li>Lowest</li>
</ol>

<p>
	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".
</p>

<h2>Sprint Planning/Backlog Refinement</h2>

<p>
	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.
</p>

<h2>Tools to Get the Job Done</h2>

<p>
	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 <code>git-web</code> 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.
</p>

<p>
	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.
</p>