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:
Let's take this example:
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:
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:
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:
https://www.mountaingoatsoftware.com/agile/scrum
http://www.methodsandtools.com/archive/archive.php?id=18
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
Links
http://agilemanifesto.orghttps://www.mountaingoatsoftware.com/agile/scrum
http://www.methodsandtools.com/archive/archive.php?id=18