Tracking Agile Projects is about monitoring the project health, and checking adherence to the schedule is a relatively simple exercise.  The amount of work actually completed in an iteration is compared with the amount of work expected to be completed.  Differentials are feed back into the amount of work expected to be completed in the future iterations, which has a self corrected effect on the project schedule.

Monitoring the Release Plan

The easiest way of showing this information is by using a release burndown chart.  This chart displays the amount of work remaining on a release and the teams progress over each iteration.  This diagram is updated at the end of each review.

The following diagram depicts a fictional project.

  • The total number of points for the release is 200
  • The estimated velocity is 20
  • The iteration length is 2 weeks
  • The red line indicates the trend line that should be followed in order to achieve completion on time.
  • The blue line indicates the actual decrease (Or burndown) following each iteration
  • The black line is a trend line for the actual burndown, indicating an estimated completion of 13 iterations.

Release Burndown

From this diagram ,we can immediately derive the following information regarding the release:

  • The average estimated velocity is slightly lower than anticipated and should be corrected accordingly
  • The project will overrun by an estimated 6 weeks
  • In iteration 2, there was actually a “burn up”, where more scope was added to the backlog than was actually completed during the iteration.
  • The significant scope change in iteration, coupled a slightly lower than anticipated velocity appear to account for the overrun.

The project manager and owner have the following corrective actions available to them:

  • Remove 3 iterations worth (60 points) from the release
  • Accept the new release date
  • Remove some features and accept a slightly later release date

Monitoring the Iteration Plan

Within an iteration, it is often more useful to monitor health at a lower level.  Task boards are the most useful way of portraying this information.  Task boards display the stories to be completed in the current iteration.  These hourly estimated tasks for each story are displayed next to the story across multiple swim lanes to represent what stage if development the task is currently in.

As tasks are started, developed, tested and verified; they will be moved across the representative swim lanes.  When all tasks relating to a story have been verified, the story itself is considered complete.

Tasks are measured in terms of hours, so the remaining estimates within the task board will be given in hours.  This allows developers to see exactly how many ideal hours they have left in the iterations.

The following diagram depicts a task board in progress.  Note that within LexAble, our swim lane for “to Verify” is called “Waiting for Testing” in order to be more explicit.Task Board

Although the task board is excellent at representing the state of the tasks and features within an iteration, it does not give a very clear picture of work left to complete.  For this, we use an iteration burndown chart, similar to the release burndown previous discussed.  Instead of summing the remaining story points, the total remaining hours should be used.

This chart shows that because the actual work completed line is below the expected, the team is ahead of schedule, but generally appears to be following the expected burndown.

Iteration Burndown

Communicating

Communication within an Agile team should be open, honest and frequent.  The charts given above very clearly denote the health of a project at a variety of scales.  Favour these lightweight diagrams over complicated and unnecessary reports.  As previously discussed, there a few formalised meetings within an Agile lifecycle, these are summarised below.

Release Planning

The first discussion, where themes and larger stories are identified and estimated.  This will output the release plan.

Sprint Planning

Completed at the start of each iteration.  Appropriately sized stories are selected and broken down into hourly estimated tasks.

Sprint Review and Retrospective

The team reviews the iteration, gathering lessons and new risks.  New features are added to the backlog and it is re-prioritised if necessary.  The project health will be reported to the owner, but this information should be freely available throughout the iteration.  Estimations are also adjusted if required.

Release Review and Retrospective

Complete release review, including lessons, risks and process improvements.  Project archival will be completed.

Agile Planning and Estimating covers the activities involved in actually planning how the software being developed is going to be built, splitting up the development into manageable pieces and deciding a schedule for the release.  This part of my Agile development guide is based on the excellent book by Mike Cohn, Agile Estimating and Planning.

 

The following picture, taken from http://www.ebgconsulting.com/WorkshopsForAgileProjects.jpg, provides a clear overview of the activities completed during an agile project.

Scrum Plan

Release Planning

A release plan is the high level plan that is used to identify what needs to be completed and what time frame is required to complete enough before a releasable product is achieved.  The release plan is also the milestone that the team will be working towards over the course of the project and is used in determining overall project health.  With this plan the team has a clear goal of not only the project expectations, but also the expectations of the team; it provides overall goals.

A project must have objectives, this is most often financial but can be evaluated in a number of different ways.  I’ll write another post of producing a business case  to detail the steps that can be taken in evaluating and justifying a project.  Realistically, a project should deliver value in the most efficient way possible.  It may be the case that realising 80% of the total value in only 20% or 50% of the time is far more desireable.  Identifying what themes are required to deliver the desired outcomes is a critical part of this stage.

A project may be feature driven or time driven.  In the former case, the team will derive a time scale by summing the points for all of the selected stories, dividing by the teams velocity (To give the number of required iterations) and then multiplying by the length of the iterations.  This will generate the expected time to completion for the project.

For a time driven project, you should calculate the amount of available story points and then proceed add stories until the allotted time has been filled.  You can determine available story points by dividing the time frame by the iteration length (To give available iterations) and then multiplying by the velocity.

In order for a sponsor to identify what the objectives, constraints and expectations of a project are, the team should have estimated any themes or stories that may have a reasonable chance of being included in the release.

With the completion of these activities, the project will have a justified reason for undertaking it, expectations of various stakeholders and both time and cost estimates.

The final stage is to sketch out at least the first iteration, and possibly an additional 1 or 2.  Planning further than this can be wasted effort as when new knowledge about the product and project is obtained, future priorities will undoubtedly change.  It is often best to simply keep the next iteration planned and ready to go, the following 1 or 2 roughly planned and the remaining stories in the backlog.

Continue reading

The tag line for the blog is “Lessons from The Code Face”, a reference to the coal face where miners would hack away at the stone in their search for black gold.  This, and the “Mining Code” title, seem to give an unfair assessment of the coding craft.  Comparing coal mining to the intricate art of computer programming?  Preposterous.  However, as I sat down to refute my own title and explain it away as simply an evocative name, I began to see correlations (Which I suspect was easier because I was actively seeking them).

Mining implies hard work, potentially long hours and a subtle skill with the tools, which are all true of coding; it also implies that anyone can just show up and start swinging an axe to get some results, but true mastery takes practice and constant improvement, which is also true in part.  More and more attributes match: a focussed purpose, teamwork and a certain element of risk taking.  Although these are arguably all attributes that constitute a recipe for greatness in any field or purpose, it does highlight that perhaps the correlation between coal mining and code mining isn’t too stretched; therefore justifying, at least partly,  my poor pun.

This blog is a way for me to reflect and codify my own lessons, offer any subjective advice that I may have to others coming into the mine and as a learning opportunity.  I hope that the act of putting these into words may consolidate my own understanding, and offer a forum for others to share their own advice with me.