One of the more prevalent methodologies as part of the agile movement is Scrum. But, like people who use the term Agile, Scrum has come to mean different things to different people. I’ve spent the past 9 years working with teams to adopt various agile methodologies, including Scrum, and wanted to spend some time offering how I normally explain Scrum to teams.
We’ll start with an elevator pitch:
“Scrum is a way to manage work by slicing the work into small chunks deliverable within a fixed timeframe by a team.”
That fixed timeframe is the magic of Scrum – the first sign of Scrum teams getting into trouble is when user stories – the standard of work within Scrum for most teams – “rollover” the defined timeframe. Of course, another sign is when teams aren’t actually delivering potentially shippable work at the end of these timeframes, but that’s a topic for another post.
To explain in a longer prose, we need to start with some basic terms. The fixed timeframe is called an “iteration” (or “sprint”) and each iteration needs to be the same length. For most teams, a chunk of work to be completed in an iteration is a “User Story”. User stories have a specific format, but suffice for this conversation that a user story should represent a chunk of work that is valuable to the business and customers, and can be delivered in the iteration.
With those two terms out of the way, we can switch to a more in-depth discussion of Scrum. Scrum is known as the “3 of 3s” (although we’ll see one of those 3’s isn’t as consistent):
- Team: The people responsible for doing the work. It’s key that this is a true definition of a team. “A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they are mutually accountable.” (Katzenbach and Smith, 1993). This is opposed to a group of people working in the same space. In Scrum, a team is responsible for delivering the work in the iteration – not individuals.
- Product Owner: The product owner is the representation of the business and end-user. They are responsible for sequencing the work that is upcoming, so the team knows what they’ll be working on in the next iteration. They should have the authority to make product decisions, and be able to communicate frequently with the team
- ScrumMaster: Scrum defines the role of ScrumMaster as a full-time position. Their job is to help the team run Scrum well, in addition to helping the team overcome things that may be impeding them (usually referred to as “impediments”). It is good to thing of them as a coach, but also as a servant leader. They should be comfortable talking to the team as well as management, but able to help the team figure out for themselves how to solve problems and communicate results.
- Iteration Planning: At the beginning of every iteration, the team and product owner have a meeting to plan out the upcoming iteration. In this meeting, the product owner shows the team the upcoming work, and the team estimates what work they can do as part of the next iteration. Sometimes work will be too large, and the team and product owner will “split” the work into two valuable chunks so that they will fit into the iteration.
- Iteration Demo: When the iteration is completed, the team demonstrates for the product owner the completed functionality. Ideally this is done by the product owner actually using the product and trying out the new features as opposed to a team-led demo. This is so the understanding of completion is clear to everyone involved.
- Daily Standup: Every day, the team and product owner meet for a short collaboration session. During this, each team member or pair answers three questions: “What did we do yesterday?”, “What are we doing today?”, “What is blocking us from continuing?”. This is called a standup meeting because ideally participants should strive to make this a short meeting, and standing is an effective way of doing this.
- Product Backlog: This is a list of everything the product owner wants delivered. The product owner is responsible for maintaining this list, and keeping it sequenced in the order she needs it delivered in.
- Iteration Backlog: This is generated as an output of the Iteration Planning meeting, and lists the work the team has committed to completing during the iteration. Generally this backlog should not change during an iteration, since iterations should be short enough to tolerate waiting until the next iteration planning meeting. The team owns this backlog, and works together to complete the items on it during the iteration while still maintaining a sustainable pace
- Burndown Chart: This shows the progress of the work the team has completed during the iteration. It requires an estimation unit be attached to each chunk of work that is consistent from iteration to iteration. For example, if a team committed to completing 7 user stories, each worth a NUT (Nebulous Unit of Time) of 2, then the team would have committed to completing 14 NUTs during the iteration. The burndown chart would then show a line from 14 to 0 on the Y-axis, and the number of days in the iteration on the X-axis. As the team completed chunks of work, the line would be tracked of the points remaining
As I mentioned earlier, the “3 of 3s” has been extended over the years. For example, many teams find great value in a retrospective at the end of an iteration, so that becomes a fourth meeting. Teams also find value in seeing the stories, and will have a visual management system like a Story Board showing the current stories and their progress.
Estimation and Scrum
I also mentioned earlier that the secret sauce of Scrum being the timeboxed iterations. However, many groups – especially managers – think the secret sauce comes in knowing how many NUTs a team is delivering per iteration. This figure is called a “velocity” and is usually a rolling average of the previous three iterations. It gives teams a barometer to figure out the cut off for how much work they can potentially do in a given iteration.
For example, if a team’s iterations looked like this:
- Iteration 1: 14 NUTs
- Iteration 2: 12 NUTs
- Iteration 3: 13 NUTs
Then during the planning of iteration 4, they should not say, “We’ll do 17 NUTs this time!”. This messes up planning for the product owner, and will likely lead to overtime and sloppy work by the team as they try to shove more work than they have ever done before into the iteration. Instead, their velocity average would say they should stick to around 13 NUTs for the iteration. As I tell teams – you can always pull in more work if you find you’ve finished everything.
However, many teams don’t call the values NUTs, they call them “Story Points” or “Points”. This leads to a competition about how many points a team can deliver, and if perhaps this iteration they should increase the points they deliver. This is bad. All estimation is a nebulous unit of time – it’s a guess. It’s made-up. It might be an informed guess, but that doesn’t change that it is still a guess. Which means that if teams are metric’d and rewarded on how many points they deliver – they are simply going to pad their guesses to hit their target. That will win you a lot of points, but will rob you of the power of Scrum.
Teams that are consistent at delivering are amazing. And that’s what you want to strive for – consistency, not high number of points.
Remember, the secret sauce in Scrum is in choosing a length of time you can be consistent about – and can deliver valuable chunks of work during.
For more information, be sure to check out the following links: