Image by Eric Kilby, under license http://creativecommons.org/licenses/by/3.0/
Inspired by the insights of our fellow Seedcamp team, uberVU, and keen to get more of a handle on the pace of our development activities, Zoombu recently started an experiment. We decided to try ‘scrum’. No risk of cauliflower ears here; we are referring to the agile development approach which is advocated by many teams for the most effective development.
Scrum has a few basic elements, and here is how we have interpreted them:
- All development ‘stories’ are listed in the ‘product backlog’. This is a laundry list of all the items that need building with estimates of relative size – in our case we’ve listed about 145 items.
- Each product release is carved up into ‘sprints’ of defined and equal time. The focus for each sprint is on producing a working build by selecting and implementing a set of items from the product backlog into the ‘spint backlog’.
- The sprint backlog should contain estimates of all the tasks involved to complete each story.
- Teams meet every day for 15 minutes to discuss progress that day, plans for the next day and any issues holding up progress. These meetings are the ‘scrums’.
- There is a ‘scrum master’ who chairs the scrum and keeps a track on the product development progress. [Ours is thinking about getting a special hat because the title seems to warrant it – maybe a scrum cap?]
- The scrum sessions should uncover the developers’ estimates of how long is left to complete each task. This helps you to construct a ‘sprint burn chart’ where you can quickly see whether the pace of development is as expected.
- At the end of each sprint the product should be ‘done’ – that is tested, user acceptance tested, and live.
We have opted to try out weekly sprints, so every week we are adding a bit more functionality (as well as fixing bugs, refactoring, etc.) then pushing out a new release. With each new release we are inviting more trial users to take a look and provide feedback. This is essentially our user acceptance testing and already proving to be vital in terms of feedback and insights.
We are controlling the pace of invitations quite carefully, so that we can respond and incorporate the valuable feedback. Steve Krug in his book ‘Don’t make me think’ recommends that User Acceptance Testing (UAT) should take place with 3 – 5 people initially so we’ve started with low numbers and will ramp up each week as we iron out some of the more obvious items. If you have signed up to test the alpha version of Zoombu, we know you are there and thank you – we will be in touch with your invite in due course!
Week three into the experiment and scrum has already really helped us to gain focus on what’s important now and to show progress to our user community but also to ourselves. The scrums are invaluable for communication with the whole team and we are finding the burn chart a great way to track estimates vs. reality and get a clearer picture of the effort involved to complete particular stories. We came across a couple of useful resources for those people thinking of repeating our experiment in their dev team: a (less than) ten minute introduction to scrum, a Jeff Sutherland Google Techtalk “Scrum Tuning: Lessons learned from Scrum implementation at Google” , and a handy backlog and burn down template.
Posted by Rachel
