Agile Engineering - Continuously Monitoring the Sprint

TenForce Donuts

Our pmScrum software is developed using agile engineering. To make sure we don't let go on that one, we created our scrum monitor to continuously monitoring the status of our sprint.


Our pmScrum software is developed using agile engineering techniques. One of our references, to check if we are doing it correctly, is the JoelTest. We try to stick as close as possible to the Joel Test.
(http://www.joelonsoftware.com/articles/fog0000000043.html).

 

The Joel Test is basically a list of questions you can answer with a simple yes/no:

 

  • Do you use source control?
  • Can you make a build in one step?
  • Do you make daily builds?
  • Do you have a bug database?
  • Do you fix bugs before writing new code?
  • Do you have an up-to-date schedule?
  • Do you have a spec?
  • Do programmers have quiet working conditions?
  • Do you use the best tools money can buy?
  • Do you have testers?
  • Do new candidates write code during their interview?
  • Do you do hallway usability testing?

 

Every yes is one point. If you score 12, you are great, an 11 is tolerable, lower is 'ouch'.

 

Of course we are not running through this list all the time. To make sure we give all burning issues the right attention we created a scrum monitor to see those tests. The scrum monitor is linked to our bug tracking tool using our own API. Our monitor is divided into 6 panes.

 

scrummonitor

 

Pane 1: This is the burn down graph of the current sprint. This burn down graph gives us an indication how are sprint is going; will we be able to deliver all our stories before the time runs up.

 

Pane 2: This gives us the evolution of open bugs. Before we start working on the user stories, we fix all open bugs.

 

Pane 3: Shows the current number of open bugs. We aim to have this number always below 20 bugs.

 

Pane 4: This pane indicates if we have problems with are daily unit tests. If this pane is red we stop the work and fix the unit tests first. Nobody will be able to checkā€‘in code into our source control without having the unit tests green again.

 

Pane 5: This pane indicates if we have problems with our continuous-integration tests. Those tests run with WatiN (http://watin.org/) and will try to detect issues on the screen.

 

Pane 6: Shows an overview of the not tested bugs. We force ourselves to unit test or watintest every bug so we are sure that it will never reappear again. This indicator should be zero.

 

We now started with sprint 101 and as you can see both the unit tests, and WatiN integration test are green. Everybody is working to get the open bugs to zero so we can start with new functionality in our current sprint.

scrummonitor