Scrum is a light-weight Agile methodology well adapted for risky projects with dynamic requirements and small teams (generally less than 12 people). It is based on the concept of iterative development. Small releases are frequently delivered and just-in-time plannings are used instead of scheduling all tasks in advance.

In Project Management, the three main components are Time, Features and Quality. Unfortunately, these three elements are influencing each others and are not owned by the same group of people.

project management triangle

Scrum helps is smoothly handling this problematic by using simple methods.
The Life-cycle of a Scrum project (called a Sprint) is showed below:

scrum life cycle

Product Backlog

The Product Owner produces a list containing ALL the features the product will ultimately include at the end. This is called the Product Backlog. This list should includes at least the following information:
  • Id
  • Name
  • Importance
  • Estimate (in ideal man-days)
  • Demo scenario

Sprint Backlog

What is a Sprint?

Each iteration (generally 1 to 3 weeks) is called a sprint. A sprint must be considered as if it it was the last one. The sprint's deliverable must be a fully operational product. Each days starts with a stand-up meeting (lasting 15 minutes max) gathering the whole team. Everyone tells what he has achieved the previous day and what he is planning to do this day. At the end of the sprint, a demo session occurs where the development team demonstrates what they have achieved.

Sprint Planning

Each sprint begins with a sprint planning meeting. This meeting is the place where the prioritization of features in the Product Backlog is done. The product owner and the development team discuss together about each feature in the Product backlog and reach a consensus on Importance of each of them. The development team indicates the Estimate.

Let's take this example:

Product Backlog
Id Name Importance Estimate (ideal man-days) Demo scenario
1 feature 1 2 6 ...
2 feature 2 10 3 ...
3 feature 3 3 3 ...
4 feature 4 6 1 ...
5 feature 5 4 4 ...
6 feature 6 2 2 ...

At this point in time, we know in each order the features will need to be implemented.
If we re-order the table by importance and add a cumulated estimate (in ideal man-days) column, it will give us:

Re-ordered Product Backlog
Id Name Importance Estimate (ideal man-days) Cumulated Demo scenario
2 feature 2 10 3 3 ...
4 feature 4 6 1 4 ...
5 feature 5 4 4 8 ...
3 feature 3 3 3 11 ...
1 feature 1 2 6 17 ...
6 feature 6 2 2 19 ...

We still have to estimate how many features we can include in this sprint. Here is the process to estimate how many features we can develop in the time provided.

scrum flow

The duration of the sprint (that is a fixed parameter) is known at this point. Let's say we decided the sprint would last 2 weeks.
We have 2 developers in the team: Paul and Harry.
During these 2 weeks we will have 13 man-days available:

Availability Reason
Paul 5 days 50% part-time
Harry 8 days 2 days of vacation
Total total available man-days = 13  

During the previous sprints, we calculated a focus ratio of 80%. We can then deduce the total available ideal man-days.
total available ideal man-days = 13 * 80% = 10.4

This means that we can safely estimate we will be able to develop the 3 first features:

Sprint Backlog
Id Name Importance Estimate (ideal man-days) Cumulated Demo scenario
2 feature 2 10 3 3 ...
4 feature 4 6 1 4 ...
5 feature 5 4 4 8 < 10.4 ...

Burndown Chart

Now that we have estimated the number of features to include, we can start drawing the Burndown Chart. This chart includes:
  • a theoretical linear trend representing the theoretical progress
  • a curve showing the actual progress
Each day, the current status is added to the chart to compare the actual progress to the theoretical one. This allows to dynamically adjust the sprint backlog by adding/removing some features to/from it.

scrum burndown chart


Books about Scrum

Support XQual and click on one of the images below to buy a book about Scrum from Amazon.