Skip to content
Permalink
master
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

foundation/06 Burndown Charts.md

Go to file
 
 
Cannot retrieve contributors at this time
Burndown Charts 1 Sprint Review 2 Sprint Planning Meeting 2.1 An Example Burndown Chart
57 lines (40 sloc) 2.8 KB
Raw Blame
Open in GitHub Desktop

Burndown Charts

Resources:

  1. Lecture slides

1 Sprint Review

At this stage you have completed your first sprint making use of a Kanban board. During the first lab schedule a 30min meeting with the client (lab tutor) to perform a review meeting and the planning meeting for your second sprint.

Before this meeting:

  1. Check that the product demo will run correctly.

During the review meeting you should follow the following steps:

  1. The product owner should discuss the user story you completed last sprint and run a demo to demonstrate ot works.
  2. Let the client give you feedback and add any points raised as GitHub issues.

2 Sprint Planning Meeting

This should commence at the end of the review session.

  1. Discuss the remaining user stories in the left column of the KanBan and, working with the client decide on the updated priorities.
  2. Take the top story and discuss this with the client to gain an understanding as to the detailed requirements. The product owner should ensure this is documented using diagrams and notes. It is probably easiest to produce these on paper and photo or scan afterwards.
  3. All notes to be digitised and added as comments to the user story.

Once the client has departed:

  1. Any issues raised during the review should be added to the To do column in the Kanban.
  2. The detailed notes should be used to break the story into small tasks and added to the To do column.
  3. The team should play planning poker to estimate how long each task should take:
    1. Use 1-4 fingers to indicate the number of hours. If there is a difference in estimation between the team members take a few minutes to understand why thenvote again.
    2. If you think it will take longer display all 5 fingers. This wil trigger a discussion on how it can be broken into smaller tasks.
    3. Add the agreed estimation to the task.
  4. The Scrum Master adds up all the estimated durations and uses this to construct the burndown chart.
    1. You will have to agree how many days (daily standup meetings) you will need.
    2. From this you can calculate the optimal burn rate (how many of the estimated hours need to be completed each day).

2.1 An Example Burndown Chart

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