This week Web Services started a new way of running some of the projects we undertake. It’s still early days (five of them!) but I thought it might be useful to explain what we’re doing so that we can reference it in future.
The system we’ve adopted is called Scrum – the name comes from the game of rugby – and is a commonly used agile development technique.
As with any project management system there’s a whole load of terminology and scrum is no exception. We’ve got pigs and chickens, scrum masters, product owners, sprints, backlogs and daily standups! I’m not going to explain everything now but here’s a few of the things we’ve done this week. I’m sure we’re doing some things “wrong”, but that doesn’t bother me too much.
The first project we’ve introduced this technique to is the migration of the staff intranet into GO. We’ve set ourselves an ambitious timescale to get it moved across by the end of the year and it has a good balance of development, design, content creation and training meaning everyone in the team is involved. Again, there will be more information about the intranet to GO migration coming out soon!
I was advised by Alison Wildish Kerwin (formerly of this parish) that the roles of product owner and scrum master should be distinct so Steve, whose work for the Faculty of Health involves a lot of development work on GO, agreed to take on the latter role.
The process started off at the end of last week when Steve and I – now undertaking the role of product owner – met to draw up the product backlog. This is the list of things that need to be done on the project. We already had lots of things to do to GO and added in a bunch of jobs related to the migration. We tried to make sure each job was well defined so that anyone undertaking the task could get going straight away.
Fast forward to Monday morning, 10am and our first team scrum meeting. After I’d explained what I understood it to be about we took a break to play poker.
Before I get into trouble, we weren’t sat round a table with a stack of chips playing Texas hold’em, we were playing Planning Poker. This is a way for the team to collectively decide how difficult each task is. In our case we’re using story points instead of time as a measure of complexity as everyone has different skills so what takes me a few hours might be done by someone else in a matter of minutes, but the complexity doesn’t change.
Aside: I’ve seen some really nice planning poker cards from Moo and other companies but I’m cheap and don’t want to pay $$$ for them so I made a set with a marker pen and some of the hundreds of old business cards that are in my drawer!
In Planning Poker, each task is read out and players each choose a card. If there is a consensus, the ticket is allocated that point score, otherwise the highest and lowest players are given the opportunity to argue their case. The process is repeated until there is agreement before moving on to the next ticket.
Once this was finished I quickly sorted through the tickets and gave each a priority from one to five before passing the product backlog back to the team to select tasks. Some tasks were selected by individuals, others by pairs to undertake during the first sprint. I didn’t try to influence this process too much but if a job was selected, it had to be completed by the end of the week.
Nine tasks totally 65 story points were selected to form the Sprint #1 backlog and the project was now underway.
Sprints are short, iterative cycles in the project development where each final output should be a “finished” product. I consider finished not necessarily to be something we’d release to the public but at least something that we’d show to stakeholders and clients. In most scrum teams, sprints are 30 days long but I think this is probably too long for many web development projects where there are fewer hard software engineering problems.
So we have adopted one week sprints. This may turn out to be too short but for now it’s giving us the opportunity to see how the cycles work in a shorter time.
Each day at exactly 11am we have our “daily standup”. So far there hasn’t been much standing up going on but I can let that slide. Each person in the team has the opportunity to say:
- What they did yesterday
- What they’re doing today
- Any problems preventing them from achieving their goal
These meetings last at most 15 minutes (and so far much shorter) but are really useful to give everyone an awareness of how the project is progressing. As tasks are completed they are closed in our ticket tracking system and we can update our burndown chart. This is a graph showing how many story points are outstanding each day and means we can see at a glance how work is progressing.
Today after the daily scrum meeting we took the remaining items from the product backlog (with a few additions) and started the next cycle, first playing planning poker, then choosing tickets to undertake next week. For next week we’ve introduced one task from another project – Topics/125 – and we’ll be using scrum for more work over the next couple of months while we assess its long term effectiveness.
So that’s all for our first week of scrum! I need to thank Alison and Andy Male from the University of Bath Web Services. They’ve been very patient in answering all my questions about how they use scrum over the last few weeks (and months!).