summaryrefslogtreecommitdiff
path: root/posts/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.html
blob: 0e654a8e2021348369ca84a2d696734f4e8f2acb (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
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="/software.html">
            <img src="/includes/icons/floppy-variant.svg" />
            Software
          </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>