summaryrefslogtreecommitdiff
path: root/posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.html
diff options
context:
space:
mode:
Diffstat (limited to 'posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.html')
-rw-r--r--posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.html203
1 files changed, 203 insertions, 0 deletions
diff --git a/posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.html b/posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.html
new file mode 100644
index 0000000..0d5fffe
--- /dev/null
+++ b/posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.html
@@ -0,0 +1,203 @@
+<!DOCTYPE html>
+<html>
+ <head>
+ <link rel="stylesheet" href="/includes/stylesheet.css" />
+ <meta charset="utf-8" />
+ <meta name="viewport" content="width=device-width, initial-scale=1" />
+ <meta
+ property="og:description"
+ content="The World Wide Web pages of Adam Carpenter"
+ />
+ <meta property="og:image" content="https://nextcloud.53hor.net/index.php/s/Nx9e7iHbw4t99wo/preview" />
+ <meta property="og:site_name" content="53hor.net" />
+ <meta
+ property="og:title"
+ content="Useful Sprint Planning from a Certified Scrum Master"
+ />
+ <meta property="og:type" content="website" />
+ <meta property="og:url" content="https://www.53hor.net" />
+ <title>
+ 53hornet ➙ Useful Sprint Planning from a Certified Scrum Master
+ </title>
+ </head>
+
+ <body>
+ <nav>
+ <ul>
+ <li>
+ <a href="/">
+ <img src="/includes/icons/home-roof.svg" />
+ Home
+ </a>
+ </li>
+ <li>
+ <a href="/info.html">
+ <img src="/includes/icons/information-variant.svg" />
+ Info
+ </a>
+ </li>
+ <li>
+ <a href="https://git.53hor.net">
+ <img src="/includes/icons/git.svg" />
+ Repos
+ </a>
+ </li>
+ <li>
+ <a href="/hosted.html">
+ <img src="/includes/icons/desktop-tower.svg" />
+ Hosted
+ </a>
+ </li>
+ <li>
+ <a type="application/rss+xml" href="/rss.xml">
+ <img src="/includes/icons/rss.svg" />
+ RSS
+ </a>
+ </li>
+ </ul>
+ </nav>
+
+ <article>
+ <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>
+ </article>
+ </body>
+</html>