It’s impossible to describe the variations of Scrum in a few hundred words.
If you want a good introduction, come to one of my introduction workshops.
However, what I will do is describe how I’ve generally* used Scrum in the businesses I’ve helped:
- Scrum is one approach that applies the agile principles
- It is a framework; not a full methodology
- Scrum uses iterations to deliver regular working software
- Iterations are normally between 1 and 4 weeks in duration (I found 2 weeks is usually about right)
The team comprises the people who write the code, run the tests, etc. I cheekily refer to the team as “the people who do the work”. Teams are typically 5 to 9 people. The team makes decisions as a whole, not as individuals (e.g. how much work to do in the next iteration).
The Product Owner is a decision-maker from the business. The PO owns the roadmap and the backlog of work that the business wants the team to deliver. The PO decides on the priority of this backlog and will answer questions that the team might have regarding these requirements.
A ScrumMaster is often referred to as a “servant leader”. He/she is not a decision-maker but works for the team to remove impediments, coach the team in agile/Scrum processes, shield the team from negative forces, facilitate meetings, etc. The ScrumMaster works towards the team becoming self-managing.
User stories **
Scrum doesn’t use lengthy specs; instead, the PO writes a short, simple description (in everyday language) of what the business wants. This is called a “user story”. Stories are written from the perspective of the person who will use the new capability. It is important to note that the story tells the team what the desired outcome is, but does not tell the team how to deliver the requirement.
A common format used to write user stories is:
As a <who>
I want <what>
So that <why>
For example, “As a customer I want to be able to edit my shipping address so that orders get delivered to my correct address.”
User stories are supported by Conditions of Satisfaction. These are a list of criteria that the story must satisfy once delivered. A story is not considered complete until all the Conditions of Satisfactions have been fulfilled.
As mentioned above, the PO decides on the priority for all remaining work. This forms the “product backlog”. Items that are at the top of this queue will have a lot more detail than items towards the bottom. There is little value adding a lot of detail to stories that are at the bottom of the backlog because a lot might change before you get around to working on them.
Teams decide how much work to complete in each iteration by taking the top items from the product backlog. The group of items that they agree to work on in the iteration is known as the “Sprint backlog” (or “iteration backlog”).
But how do they know how much they will be able to complete? They estimate how big each story is but, rather than use time, they use story points.
The team discusses the story until they understand the requirements. They then compare the size of the story relative to other/past stories (including all testing required to make the story considered ‘done’). A popular method is for each person to choose a figure from the following sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100. Everyone then declares their opinion at once. The people who choose the lowest and highest figures then explain why they chose those numbers, the team discusses, then votes again. Once a consensus is reached, that is declared the size of the story.
This information gives the PO the chance to descope and/or deprioritise the story (or, of course, to leave it as it was and in the same place in the prioritised list).
For more information on poker planning, check out Mike Cohn’s explanation of Planning Poker.
A method to visualise an iteration’s progress: a column for each step of the process. Each story is represented by a card (sometimes the story is broken down into smaller tasks which are also displayed on the board), which is then moved through the columns as it progresses to completion.
A basic board might have columns of just ‘To do’, ‘In progress’ and ‘Done’.
Daily stand-up (aka Daily scrum)
A short, daily meeting. This is not for the management’s benefit; it is to update the rest of the team on progress – and to allow the team to offer assistance if necessary.
Common format is for each person, in turn, to confirm:
- What I did yesterday
- What I plan on doing today
- Any impediments that I have
Once you’ve run an iteration (or five), you will get an idea of how many story points you are likely to complete each iteration (by taking an average). This is your velocity.
Be careful! Velocity should not be seen as a promise, a target or a management metric; it is meant as a guide for the team to limit the amount of work they are saying they will complete in each iteration.
A chance for the team to show-off what they have produced and gives the business an opportunity to see new functionality.
Note: this is a demonstration, not a training session.
At the end of each iteration, the team will get together to discuss how well they worked as a team and what they can do to improve.
It is not a meeting to discuss individual performances, nor is it the time to discuss feedback from users on individual stories.
A common format is to highlight:
- What we should start doing?
- What we should stop doing?
- What we should continue doing?
Definition of done
Unlike Conditions of Satisfaction, this is criteria that all stories must satisfy before they can be considered done.
For example, the team might decide that every story should be code reviewed by at least two other people, must have undergone testing and must be merged to a specific place on the server.
It is important, again, to note that it is the team that agrees its definition of done.
The team’s Definition of Done is usually printed out and placed near the Scrum board.
A burndown chart helps the team track progress.
The x axis is time. The y axis shows points/days/hours of work remaining.
Each day, the team will calculate the story points or time remaining, and plot it on the graph.
I struggle to see the benefit of calculating days or hours as we have already established that we struggle to estimate time more than we do relative size. But this is widely argued and is just my personal opinion.
I hope that helps give you an overview of the basics of Scrum. Please contact me if you have any questions.
* Please also note that, in order to get a brief summary written, I have made some very large generalisations. If you would like to suggest how I improve this page without making it 20 times larger, please feel free to let me know.
** Some of the practices detailed actually originate from other frameworks, such as XP. However, they are now commonly used by teams using Scrum.