Burning down hours, burning up coffee

My game development studio decided, at the end of Sprint 2, to start tracking how many cups of coffee they consume from our communal Keurig each day. Truly, this is an exceptional team in terms of coffee consumption, and they recognized this might be an interesting bit of data to track. They finished Sprint 3 last Friday, and so today I tallied up the results on the coffee tracker, and I added a new vertical to the burndown chart:

The careful observer will note that I had a bit of trouble placing the dots, since we're measuring cups of coffee consumed on a different scale than hours burned down. Hours remaining are counted at the beginning of each MWF meeting, so the first data point is the total original estimate and steady leads to zero. For coffee, we're counting cups consumed each day, including the first and last days.

To facilitate smoother tracking for Sprint 4, I added a new right vertical to my template:

Time will tell if the right vertical axis values are correct.

A semester in five burndown charts

It's the end of the semester here, and I am looking forward to writing a bit about the semester once its behind us. In the meantime, here's a visual vignette about my Game Programming course. We had a great team of students working on original video games with a community partner. The semester was divided into five Sprints, following the principles of Scrum. We used burndown charts to track progress throughout the Sprint, plotting actual hours remaining (green) against steady progress (blue).

I find that these five images tell an interesting story of a team's progress. The students had never worked together before, and most of them had never been part of an agile team. They were learning not just technical skills but also professional and social ones. The charts illustrate this learning during the semester, as they improve with their abilities to estimate, to plan, to deliver technical results, and to respond to changes.

That bump in Sprint 2 is interesting. The team recognized that many problems in the first sprint came from a combination of procrastination and poor estimation. They started in on their tasks right away in Sprint 2, and when things didn't go as well as hoped, they blew up the estimated hours remaining on those tasks. It turns out that the tasks weren't as bad as they feared, and as they worked through their problems, the estimates dropped back down to more accurate levels.

The erratic path in Sprint 5 illustrates that the team underestimated the effort required to polish the games for public release. Interestingly, the burndown chart was still useful even though the estimates were quite wrong. The team could look at the chart, which said they were dozens of hours ahead of steady, while knowing that there was still significant work to be done. This discordance forced them to re-evaluate their tasks and estimates, to reconsider the sprint's plan, and eventually, to successfully deliver on every user story.