From 093425e240308f097f341bd214a45cd976e89ae2 Mon Sep 17 00:00:00 2001 From: "Adam T. Carpenter" Date: Tue, 8 Dec 2020 14:33:03 -0500 Subject: added tox to contact, added scrum planning post --- ...int-planning-from-a-certified-scrum-master.html | 209 +++++++++++++++++++++ 1 file changed, 209 insertions(+) create mode 100644 posts/programming/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.html (limited to 'posts/programming') diff --git a/posts/programming/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.html b/posts/programming/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.html new file mode 100644 index 0000000..2334b39 --- /dev/null +++ b/posts/programming/2020-12-08-useful-sprint-planning-from-a-certified-scrum-master.html @@ -0,0 +1,209 @@ + + + + + + + + + + + + + + 53hornet ➙ Useful Sprint Planning from a Certified Scrum Master + + + + + + +
+

Useful Sprint Planning from a Certified Scrum Master

+ +

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

+ +

Points as a Measure of Work

+ +

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

+ +

+ Some teams have a special system for incrementing points. Our team uses + the + Fibonacci sequence of numbers. 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. +

+ +

How Much is Enough?

+

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

+ +

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

+ + + +

Prioritizing Work

+ +

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

+ +

+ To communicate how "important" a task is, every story we have is + prioritized something like this: +

+
    +
  1. Critical
  2. +
  3. Blocker
  4. +
  5. Highest
  6. +
  7. High
  8. +
  9. Medium
  10. +
  11. Low
  12. +
  13. Lowest
  14. +
+ +

+ 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". +

+ +

Sprint Planning/Backlog Refinement

+ +

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

+ +

Tools to Get the Job Done

+ +

+ 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 git-web 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. +

+ +

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

+
+ + -- cgit v1.2.3