An Overview of the Scrum Process
Scrum is a simple framework that does not demand any special tools or software. Here we explain how a project typically is run using Scrum.
Before we can start to use Scrum on a project, there needs to be a Product Backlog.
A project's Product Backlog is, in its most basic form, a list of everything that needs to be done in order for the project to finished.
You can read more about creating and maintaining the Product Backlog here.
Once we have a Product Backlog the Product Owner can start to build a release plan for the project.
The Product Owner needs to take a look at the Product Backlog and prioritise it with respect to the business value each item in the Product Backlog has for the project stakeholders.
The Product Owner can then start to determine how much of the Product Backlog needs to be developed in order to be considered a releasable product and a rough idea of when it should be released.
The Product Owner begins to specify the highest priority Product Backlog items in such detail that they can be presented to the Scrum Team for high level/rough estimation.
If the Product Backlog is large enough to cover a number of Sprints, the Product Owner only specifies in detail those Product Backlog items that will be a part of the coming Sprint and some or all of the Product Backlog items for the next Sprint again. This is to avoid wasting time specifying Product Backlog items that may not end up being part of the final product due to changing requirements.
It is the responsibility of the Product Owner to maintain the Product Backlog for the duration of the project.
A Sprint is the name given to a period, typically 1 to 4 weeks in duration, in which the Team works on delivering a number of features pulled from the Product Backlog list. The result of a Sprint should ideally be potentially shippable product.
At CoreWorks, we typically run 14 day Sprints, which start on a Friday and run through to Thursday.
Why start the Sprint on a Friday? Teams returning from a weekend are motivated and eager to start doing the work they love doing. However, starting a new week off with a planning meeting lasting several hours really takes the edge off the Team's enthusiasm. We feel the best way to serve the Team is by running Sprint Planning Meetings on a Friday so when the Team comes in on a Monday morning they are fully loaded and ready to start the Sprint.
A sprint kicks-off with a Sprint Planning Meeting, followed by a number of days working on tasks from the Sprint Backlog, and ending with a review of the Sprint.
Sprint Planning Meeting
On the first day of a Sprint the Product Owner and Team meet for the Sprint Planning Meeting. The Sprint Planning Meeting is held in two parts:
- Product Backlog Presentation
- The Sprint Backlog
Product Backlog Presentation
In the first part of the Sprint Planning Meeting, the Product Owner presents the Product Backlog to the Team. The Product Owner does so in order of priority and it is the Teams job to ask questions to ensure they have enough information for each item in the Product Backlog to break them down into Tasks.
The Sprint Backlog
The Sprint Backlog is the Team's list of features they are committed to work on in the Sprint. It is generated by the Team by pulling the highest priority item on the Product Backlog list, breaking out tasks for that item, committing to the item and repeating the process until the Team cannot commit to more work. In this way the Team decides how much work they can commit to for the Sprint.
Sprint Daily Routine
Once the Scrum Team has a Sprint Backlog broken down into tasks, the Sprint Backlog Items/Stories) and their tasks are placed upon the Scrum Task Board. The Scrum Task Board is a central component of daily life for the Scrum Team and is used to track the Scrum Teams progress throughout the Sprint and is the gathering point for the daily Scrum meeting.
Each day the Team holds a Daily Scrum Meeting. Here each Team member is asked three questions:
- What did you do yesterday?
- What will you do today?
- Is there anything standing in your way?
The meeting centers around the Scrum Task Board, which is updated by Team members, and lasts a maximum of 15 minuets and is a way for the Team stays informed on what each member i working on and to identify any issues that are getting in the way of the Teams progress.
Sprint Burndown Chart
The Sprint Burndown Chart is used to daily record the Teams progress on the work the Team has committed to deliver by the end of the Sprint. It gives a quick way to determine if the project is on track or not and because it is updated every day, it allows the Team to respond, if the project is running behind, and get the project back on track.
The Sprint Review
Each Sprint finishes with a review made up of two parts.
Sprint Review - The Sprint Demo
The purpose of the Sprint Demo is to allow the Scrum Team to demonstrate how they have succeeded in meeting the Sprint's goal.
Sprint Review - The Sprint Retrospective
The second part of the Sprint Review, called the Retrospective, is for the Scrum Team to look back at their performance for the Sprint and ask themselves three questions:
- What should we keep on doing?
- What should we stop doing?
- What should we try in the next Sprint?
We find it is useful to have these questions written up on a whiteboard along with the input from the Team. It is also a good idea to have a "parking space" or issues raised that are out of scope and which need to be discussed but at another time out side of the retrospective.
The Sprint Retrospective is normally exclusively for the Scrum Team. The Scrum Team uses the information gathered to improve their performance in the coming Sprint.
Repeat until done
The Scrum process then repeats until the project is completed.