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, 0 insertions, 203 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
deleted file mode 100644
index 01a9b3a..0000000
--- a/posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.html
+++ /dev/null
@@ -1,203 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
- <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 alt="home" src="/includes/icons/home-roof.svg" />
- Home
- </a>
- </li>
- <li>
- <a href="/info.html">
- <img alt="information" src="/includes/icons/information-variant.svg" />
- Info
- </a>
- </li>
- <li>
- <a href="https://git.53hor.net">
- <img alt="git" src="/includes/icons/git.svg" />
- Repos
- </a>
- </li>
- <li>
- <a href="/software.html">
- <img alt="software" src="/includes/icons/floppy-variant.svg" />
- Software
- </a>
- </li>
- <li>
- <a type="application/rss+xml" href="/rss.xml">
- <img alt="rss" 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>