Scrum

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.

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

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.

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.