Opinionated Scrum with Atoll

Getting Started

Many organizations use or have used Scrum for development. So, for many people reading this it will be something familiar. However, there's a right way and many wrong ways to do Scrum and unfortunately most organizations do it the wrong way. This document provides an introduction to doing Scrum that Atoll way aka the "right way".

How to Start

There are a few very important things you need to think about right from the start (see details in sections below this list):

1. Failure is OK.
2. Start with a "Sprint 0".
3. Continue with "Sprint 1" through "Sprint 3" without setting capacity for the team.
4. Establish capacity for the team from "Sprint 4" onward (base it on the last 3 sprint's average velocity). See "Capacity vs Velocity" below.

Failure is OK

So many companies get this one wrong. At first it may seem that your company at least has this in mind so you may think that this doesn't apply to you. You need to ask a few important questions:

1. Does your company "fail forward"?
2. Are they OK with not getting 100% story completion every sprint?
3. Do they have a minimum percentage completion that's considered successful (for example 80%)?
4. Have you ever aborted a sprint and re-started it?
5. Do they consider re-work taboo?
6. Do you do continuous refactoring or tackle tech debt every sprint?
7. Does management reward success and/or shame failure?

If "Failure is OK" at your company here's how you should've answered these questions:

1. Yes/No- this doesn't matter because technically this isn't a scrum concept... it is more about how you tackle failure when deploying to production. Still, it helps if your company culture has this attitude to production failures: just get it fixed, don't try to back it out as a default course of action.
2. Yes- this is very important... if anything you should either be getting less than 100% or more than 100%- if you're getting exactly 100% that's suspicious... or you're not being transparent about extra work you've done (tech debt etc.)
3. No- there should be no minimum if you're really OK with failure. It is OK to take issue with repeat failure though- you're meant to adjust and improve, not fail every time. The main point is that the team can take risks and fail- that should be encouraged.
4. Yes/No- this doesn't matter so much... but a team should feel OK doing this if necessary. If they don't feel that this is an option then you don't have a "Failure is OK" culture.
5. No- re-work is OK and an agile process essentially necessitates this... you're meant to do work in an iterative manner and that sometimes means you do things more simplistically at first and back that out later to put the more complex solution in place. If you or your management come from a project planning / waterfall methodology background this can easily occur. Once again, a lot of re-work is bad, but a little is expected. It is OK to monitor re-work and try to minimize it, but don't make it taboo.
6. Yes- this is very important. This is really the only way to avoid a future re-write, lots of quality problems, slower feature delivery, and/or developer frustration working with the code-base.
7. No- ideally your management acknowledges all work that's been done... whether it resulted in a new flashy UI, new API endpoints, a large scale refactor that was needed, OR a discovery that an approach didn't work and had to be backed out. The last case is particularly important because instead of band-aiding a problem the team has identified that a bigger problem needs to be resolved. The team that encounters this and acknowledges it is a mature team and they need support and encouragement. Also: organizations will have star teams that can do no wrong and other teams that appear to just get mundane work done or appear to achieve less. Very few teams are completely useless and they represent opportunities for growth (or you need to revisit your hiring practices!) and will achieve more with encouragement and mentoring.

Capacity vs Velocity

Capacity is the number of planned points that a team can take on each sprint. When planning a sprint the team should not exceed this unless they can see that their velocity has been steadily improving. They should also not try to plan meetings and other events into this capacity. Every sprint will have some disruption (team member vacation time, illness, etc.) and the velocity will show this over time. Slight adjustments to the capacity are reasonable and there are times of the year when a team has a lot more vacation time (for example, around the holidays), but this is the exception rather than the rule.

Velocity is an average of the accepted story points over the last 3 sprints. If a story has been continued to the next sprint it may be tempting to include a percentage of the points in the velocity, but that isn't valid- you can only count the points as added business value once the story has been accepted. Don't use your "Definition of Done" to determine this story state (or only count stories that have been released)- this is purely about acceptance (i.e. when the story has met its intended objectives).