David Ross's Blog Random thoughts of a coder

Sprint Milestones - A second level of reporting

13. November 2008 07:38 by David in

One of Scrum's great strengths is that it promotes transparency. 

The daily stand-up ensures that team members understand what their peers are working on.  It also helps to quickly identify cards (tasks) that were underestimated or when a particular team member or pair have become stuck and aren't making progress.  Unfortunately while SCRUM is great at managing the project it can be more difficult to present the progress to senior management.

For example which of the following metrics should be used as the public face of the SCRUM.

  • Sprint burn chart

  • Completed stories

  • Card life cycle (planned, in progress completed)

Originally my team was only using a burn down chart for reporting but in the last couple of sprints we have added the concept of Sprint Milestones.  A Milestone is

  • Scheduled

  • Dependent on a set of cards

  • Completed

Once all of the cards in the Milestone have been complete we move the Milestone card from Scheduled to Complete.  When reporting a Milestones progress we list the number of cards completed over the total number of cards (i.e. 2/6).

 The following is an example of the type of information that is placed in the fortnightly progress report that is presented to my projects steering committee.

 

Sprint: 1
Sprint Goal:  Integration between Eagle and Bloomberg
Sprint duration: (3/11 - 22/11)
Milestones:
Bloomberg market data transformed into Internal schema (3/8) - GREEN
Market data loaded into Eagle (2/5) - GREEN
Bloomberg data exported to down stream systems (0/5) - YELLOW
Sprint complete (5/18) - YELLOW
 Burn down chart:
<image here...>
Issue List:
<table of outstanding issues/external factors that are blocking the team>

 

In many ways you can think of Milestones being an aggregated view of the user stories and tasks within a sprint.  The most important criteria for determining if an item should be wrapped within an Milestone is whether it needs to be publicly reported on or whether it contains integration points with other teams and so needs to be carefully managed.

Comments are closed