Burndown Charts
You have now completed your first sprint and will need to present this to your client (the lab tutor). Once this is over you will be planning your next sprint.
Resources:
1 Retrospective
Each week the development team should meet up (before meeting the client) and ask each member of the team to identify:
- What they should continue to do (existing good practice)
- What they should start doing (new good practice)
- What they should stop doing (eliminiate bad practices)
2 The Review Meeting
The review meeting will take place in the first lab session in the week and will typically last for 30min. During this meeting you will be expected to do a local demo of the software you built during the sprint so make sure you are prepared.
The product owner should produce a one page summary of the features to be demonstrated. Use the table below as a template:
| Type | Description | Status | Demo |
|---|---|---|---|
| Story | xxx | completed | Y |
| Story | xxx | incomplete (why) | N |
| Bugfix | xxx | completed | Y |
Make sure this has been sent to the client the night before the review meeting and ensure there are paper-copies for everyone in the meeting. The Scrum Master should also ensure that there is an up to date User story map and Kanban board visible to everyone in the meeting.
- Introductions: everyone explains what they have been working on. Keep this brief!
- Explain Features: The Product Owner goes go through summary of stories and tasks completed based on the summary circulated before the meeting.
- Demo new functionality: product owner demos features and gets feedback from the client. This is recorded by all members of the team and any bugs identified are immediately added to the Kanban board.
- Discuss key events/issues: The Scrum Master now discusses and resolves issues: 1. Bugs and issues added to the issue tracker and therefore the To do column on the Kanban board.
3 Sprint Planning
Before the client leaves the meeting you will need to carry out the planning for sprint 2.
- Review of outstanding user stories with the client and re-prioritise these.
- Work with the client to agree the next priority user story (this is typically the one at the top of the list).
- Identify the user story to work on if the first is completed early (the stretch task).
- Discuss this story in detail with the client and use sketches and diagrams make sure everyone in the team has a good clear understanding of the requirements.
- A piece of good advice is to get the product owner to describe the details back to the client to ensure these have been understood.
- Add these notes and sketches to the user story.
4 Technical Planning
This sould be carried out when client has left:
- First story broken down into technical tasks
- Each task is added to the To do column
Now the team should apply the process of planning poker to each of the tasks:
- The Product Owner reads out the task.
- Each member of the team places a hand behind their back and indicates how long the task will take (in hours) using their fingers (5 fingers means the task will take longer than 4 hours).
- Simultaneously all members of the team reveal their bid.
- If all members agree on a time and it is 4 hours or less this is noted on the task and the team proceed to the next task in the list.
- If there is disagreement between the team members, pick the person with the lowest and the one with the highest and ask them to explain their choices. Then the entire team vote gain.
- If the general agreement is that the task will take over 4 hours, the team break this large task into two smaller tasks and apply planning poker to these.
5 First Standup Meeting of the Sprint
At this stage, the team will need to decide on how much time they can allocate to the sprint (in days) and agree the dates, times and venue of each of the daily standup meetings.
Each member of the team picks one of the tasks, allocates it to themselves and moves it to the In progress column.
Everyone gets stuck into the work they have chosen.
6 The Burndown Chart
Whilst the rest of the team start working on their tasks, the Scrum Master:
- Adds up all the times for all the tasks.
- Draws a chart with this total time on the Y-axis and the agreed number of days the team will be working on the X-axis.
- Draws a straight line from the end of the Y-axis to the end of the X-axis as shown below.
- Calculates the optimimum daily burn-rate (how many hours of wrork need to be completed for each sprint day). 5. This should be communicated to the rest of the team.
Here is an example of a burndown chart showing the line of optimal development. In this example the sprint lasts from Mon to Fri and there are an estimated 40 hours of development. It shows that the optimum burn rate would be 10 hours per day.
40 ║*
║ *
30 ║ *
║ *
20 ║ *
║ *
10 ║ *
║ *
00 ║ *
╚══════════════════════════
M T W T F
7 Daily Standup Meetings
As each task is completed, the member of the team responsible should immediately move it to the Completed column otherwise the Scrum Master won't be able to update the burndown chart.
Before each daily standup, the Scrum Master should update the burndown chart to indicate the amount of work still outstanding. From this it should be clear whether the sprint is ahead or behind schedule. It should also be possible to revise the remaining average burndown rate if the project is to be completed.
The daily standup should be carried out at the start of each day with the entire team present either in person or via video conferencing.
- The Scrum Master presents the latest, up to date documentation (kanban and burndown charts).
- Each member reports back:
- What did they achieve since the last meeting?
- What will they achieve before the next meeting?
- Are there any issues holding them back (anyone who can help should volunteer but not start discussing the issues)
At this point the meeting breaks up and the Scrum Master ensures that the right developers are involved in resolving the issues that arose.