From bfaccc32571df8a02f69518d8864244efba3b5b5 Mon Sep 17 00:00:00 2001
From: 53hornet <atc@53hor.net>
Date: Wed, 28 Jul 2021 10:58:58 -0400
Subject: php site, templating and partials, faster index generation

---
 ...rint-planning-from-a-certified-scrum-master.php | 144 +++++++++++++++++++++
 1 file changed, 144 insertions(+)
 create mode 100644 posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.php

(limited to 'posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.php')

diff --git a/posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.php b/posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.php
new file mode 100644
index 0000000..77aebdf
--- /dev/null
+++ b/posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.php
@@ -0,0 +1,144 @@
+<?php
+$title = "Useful Sprint Planning from a Certified Scrum Master";
+if (isset($early) && $early) {
+	return;
+}
+include($_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
+?>
+
+<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>
-- 
cgit v1.2.3