I’m using this as a learning exercise so I’ll continue with it, but some feedback would help me test my ideas and learn if anyone is interested enough to take a look at the code. I’ve focused on HTML5 local storage when building this page so that your stories are available next time you visit. Next I’ll make sure stories display in the order they were added when you return and clear the editable content when you begin to type.

Browser local storage has a lot of potential for prototyping. Having a simple way to persist data that overcomes cookie size limitations means you can try some relatively complex interactions using just HTML5 and javascript before launching into a fully fledged application. Smashing Magazine has a nice primer for local storage.

The long-term average number of customers in a stable system WIP is equal to the long-term average arrival rate, TH (Throughput), multiplied by the long-term average time a customer spends in the system, CT (Cycle-Time); or WIP = TH * CT.

Little’s law applies to all systems.  An example using Scrum might look like this:

1. 2 week sprint (10 working days)
2. 10 stories in the sprint

Assuming all stories are delivered in the sprint TH is calculated as stories delivered / time.  In this case 10 / 10 = 1.

If we’ve been imposing a WIP limit of 2 stories then we can calculate Cycle-Time: 2 / 1 = 2

In this example a story is in the system for 2 days. If we increase WIP then Cycle-Time also increases eg. 4 / 1 = 4.  Why should we care about this?  If our WIP limit is too high we will end up delivering most of our stories on the last day or two of the sprint.  We are then looking at big bang integration and other activities the Agile attempts to eliminate.

One possible reason for a burndown like the one above is that there was too much Work In Progress.  If 6 stories were in progress for a large part  of the sprint then CT becomes 6 days.  To achieve a burndown where stories are ‘done’ at regular intervals through the sprint we could take the following actions.  Limit WIP to a point where CT stablises around 2 or 3 days or improve Throughput by changing the process.

Scrum has two ceremonies where we can improve Throughput; the daily standup and retrospectives.  The standup is used to maximise throughput in the sprint and the retrospective for identifying process improvements to work on in the next sprint.

Until recently I thought that limiting tasks in progress was the throttle for WIP.  The trouble is that it’s still possible to  have a task in progress for almost every story in the sprint.  The correct way of limiting WIP is to use a meaningful unit of production. In Scrum’s case this is a story.

Pushing work into the live app before you can say it’s done means that deployment has to become part of the story.  We can’t defer the work to a ‘deployment’ story or push it outside of the sprint.  This gives us a better understanding of our velocity because stories encompass all of the associated work.

Deploying in a big bang can surface issues that nobody anticipated.  If the problem is the result of work undertaken at the beginning of the sprint it takes a little time to get back up to speed, but this isn’t a problem if you’re releasing the work as you go. Small incremental deployments mean that we don’t get that slightly anxious feeling as release day approaches.

Why doesn’t deploying to a test environment work just as well?  Until this sprint that’s exactly what we did, but with this experience it feels like a compromise. For one thing, knowing that your work is going public immediately encourages communication between developers and clients which focuses attention on the details of a story.

For me there is a lot more to learn here so I’m going to look into continuous deployment to see what techniques can be used to support it.

6 Weeks after I first suggested the idea of creating a local Scrum user group we held first meeting.  People quickly joined a hastily created group on LinkedIn and started spreading the word.  The first person to join the group was Nigel Baker, a Bristol based Certified Scrum Trainer, who kindly offered to sponsor the first meeting and present with another local CST, Paul Goddard.

The turnout for the meeting was good, about 19 people.  This was impressive considering how difficult it was to find the lecture theatre at the University campus!  Nigel and Paul presented “15 tips to do good Scrum (and more importantly, build better products!)“, which was both informative and entertaining.  This gave everyone a lot to talk about when we moved to the student bar on campus, thankfully the unexpected Mexican night had pretty much finished by the time we arrived.

Everyone at the meeting was clearly enthusiastic about Scrum and Agile development, many face similar challenges.  My hope is that members of the group will be able to support each other to use Scrum successfully.

There has been some discussion in the LinkedIn group since the meeting including ideas for a second meeting.  I’ve included these and some of my own below:

• Scrum for distributed teams
• Software to support Scrum (can they be better than a board and post-its?)
• Turning your clients into Product Owners
• Scrum or Lean?
• Starting Scrum in a Waterfall environment

Thanks to everyone who attended the first meeting and made it a successful event.  I’d welcome suggestions for speakers, venues and sponsors.  Help with arranging meetings would also be very much appreciated.  Check back here or the LinkedIn group for details of the next meeting, looking forward to seeing you all there.

I’ve started to make a few contacts in the area to find other Scrum users and if possible run a meeting in late November.  I am also wondering if it’s better to have a wider focus covering XP and agile development in general?  At the moment the attendees are myself and a colleague, my first thought for a location is the Raven.  If we get some interest (at least one other person!) I’ll set a date for the first meeting.

I’ve created a LinkedIn group so if you are interested please join or leave a comment on this post.

OK, first things first. I scored 70%. Not bad, but I have an excuse ready. I didn’t notice the timer when I started the test so I had to rush the second half and missed the last 4 questions. The test was really useful to me because a number of questions relate to the responsibilities of each Scrum role. It also touched upon the idea that if you are going to modify Scrum or can’t implement it as designed you won’t realise all the benefits.

It will be interesting to see how scrum.org develops in the near future.

Just before learning about Scrum.org I came across Ken’s Google TechTalk from 2006 – Scrum et al.

The talk helped me to gain a better understanding of what a high performing Scrum team should feel like and how each role can contribute to this. If you are thinking of starting Scrum I would recommend that your team watch this together.

After using Scrum for the last year and seeing many benefits I am really keen to bring together other Scrum teams, ScrumMasters and Product Owners in my local area to share our experiences. Living in a rugby city it’s clear that I am not going to find these people by searching for ‘Scrum Bath’. If you’re interested or know someone who might be please get in touch.

The IWMW organisers have asked people to consider using a Creative Commons license for their slides.  This made me think, why not release all the resources I have created for this workshop? People would then be able to run the workshop themselves and demonstrate the main concepts of Scrum to development teams, managers or clients.

A workshop like this could help if you want to start using Scrum. At a glance Scrum can seem to advocate chaos in teams, but when you’ve experienced it you realise this isn’t the case.  The people who have trialled this workshop have said that the exercise shows how Scrum can help you make realistic commitments and plans.

At the end of his post I have included a couple of story cards which are part of the exercise. I’ll release everything after IWMW 2009.  The priority and story points are empty as the whole group will be estimating each story before the building begins.

With 6 days of the sprint left we only have 1 story that isn’t in progress, and someone has committed to completing that tomorrow. If, for some reason, we wanted to pull a story out of the sprint now and replace it we couldn’t recover the time we had spent on the story that was already in progress. Closing the backlog to further changes lets us focus on achieving the sprint goal.

It’s uncomfortable to say that the backlog must close. If we realise that a story no longer has any value then we shouldn’t give it any more time. One option is to drop the story, accept that we lost some time and be happy we won’t waste any more. Can we do better though?

We estimate stories using points and don’t do hourly estimates on the associated tasks. If we did hour estimates or tracked hours remaining then it might be possible to work out which stories we could move in. We would understand what time that had been spent on a story and make sure any new story would fit into the sprint.

The open backlog has been really helpful in the first 2 weeks of the sprint. If we do have to close the backlog now I think we can still be pleased with the flexibility we had until this point. Maybe the retrospective will throw up some ideas for allowing us to keep the backlog open for longer.

• Deliver value early
• Embrace & adapt to change
• Provide visibility of work
• Promoting conversation

If you are attending it would be helpful if you could give me an idea of your role and what you hope to get out of the workshop.

At this stage I plan to cover the topics below and to run activities that demonstrate the Scrum framework.

Topics

• Where does the term Agile come from?
• What problems does Scrum solve?
• Why Scrum can be valuable to Web Teams in HE
• Scrum forces you to be realistic
• Outline of the framework
• What problems does Scrum create?
• Team organisation for Scrum
• Agile development practices
• How to begin Scrum

Activities

• Estimating work
• Planning poker
• Retrospectives

I’m planning the group activities and will aim to post some details early next week.  I am wondering if I could run the Scrum Lego game, but I’m not sure where I can get enough Lego.