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
|
<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>
|
