Visualising a sprint
It’s been two weeks since the
At Desktop & Services department at TomTom we have been practicing the agile approach to developing software for a while already. Morning stand-up meetings, timeboxed sprints… our team worked like this for nearly nine months. While we did get the basics more less right, some essentials we were still missing. So we started working on resolving them. Besides resolving the major issues, we also started changing small details of how we worked. One of such changes was the way we visualise a sprint. Seemingly a trivial change proved to be a quite important one. Until the last sprint, I’ve always been wondering how to administer the sprint tasks the way that (1) all team mebmers could get easy overview of the status of all tasks, (2) the product owners could review the status without having to talk to the Scrum Master, (3) Scrum Master could avoid mailing the information around or engage in daily task list printouts.
We used to use the MS Project to plan the sprints. Using the MS Project proved to have many limitations: the waterfall Gantt chart being generated for anything we planned, sharing the status of the sprint always involved printouts and the printouts which were becoming obsolete in matter of hours. Editing the source file by more than one person at time was impossible. With the developers starting to use various flavors of operating systems on their work stations, we finally decided to ditch using this proprietary tool (and to save a tree, too!). A brief experience with using the MS Excel brought exactly the same problems. Jira served us well all that time to work with bugs, using it for documenting the spritns didn’t really work either.
The answer to all above problems was… the Scrum Board! Jeff showed us some sample photographs and we also found great inspiration in Henrik Kniberg’s “Scrum and XP from the Trenches”. We’ve confiscated an unused white board and turned it into a Scrum Board in no time. The result? Everyone can now clearly see the status of the work items. No print outs or status reports needed anymore. This really saves us a considerable deal of time. The burndown chart is a great velocity indicator and a good source of motivation, too. And last but not least – the developers are having fun working with it.
We completed our first sprint using the Scrum Board. It is clear that we will continue using it for time being!