So we've just started our fifth two-week sprint since we adopted Scrum at Future Platforms; it seems like a good time to write about the things we've learned so far (and the stuff we still don't get).

At the end of each sprint we devote a day (which Joh ably facilitates) to reviewing the previous two weeks and planning out the next two; in the morning, we first review what was produced in the previous two weeks, then have a retrospective where we talk through what went well, what went badly, and what we still don't understand. The first review lets Devi, our product owner (a role which seems to map well with account manager) and the team themselves get a good view of what's been done, while the retrospective lets us all identify what's working and what needs to change. Typically we end the retrospective with 4 things which we aim to concentrate on in the following sprint; these have included items like "reducing interruptions", "try pair programming", "manage contacts with clients via correct routes", and so on.

Having spent the morning reviewing the previous two weeks, we spend the afternoon of the planning day looking at the next two weeks: taking stories which together make up a product, prioritising them, estimating them if necessary, and getting them up onto the task tracking board. In the early sprints we found the estimation of tasks to be an horrendous burden, and 3-4 hour sessions of estimating tasks were (understandably) unpopular. Nowadays this seems to take much less time, mainly because we're breaking down projects into stories and estimating them during our pre-sales process (i.e. in a fairly piecemeal way) rather than doing it all at the planning meeting. We've also found that planning poker speeds up the estimation process significantly, focusing debate where it's needed most - i.e. where there's most dispute over the scale of a task. Nevertheless these planning days are still quite gruelling for everyone involved.

At the end of each sprint, we tot up how many hours of planned work actually got done, and I calculate the ratio of total available hours to hours of planned work. This tells us how much time each hour of estimated work actually takes us, and I'm quite surprised at how consistent this number is; over the course of 4 sprints we have a *very* consistent picture of how long an hour of planned work takes us, and this picture is useful - both in showing that there's room for us to improve, and letting us make commitments to clients based on evidence, not prayer.

In the early sprints, we had a lot of work which "just had to happen" - like many companies of our size, I suspect - and we consciously planned in more than our initial figures showed us we could realistically handle. Overcommitting in this regard didn't actually get more work done, even when the team visibly felt the additional pressure. This sprint, we've taken care to not repeat this pattern and have planned in what we know to be an achievable quantity of work, based on what we achieved over the previous few sprints. To try and increase our efficiency, we've reduced the number of simultaneous projects we're running - as a service company it's unusual for us to focus the whole team on a single client, but reducing the number of projects for the team from 4-6 down to 2-3 per sprint might make a difference. We'll be able to see if it's made a difference in just under 10 days time, when we look at figures for work completed, of course. As the owner of the business, I like being able to measure this sort of thing empirically - though it does mean that we have to spend a bit more time on release planning, to ensure that if we have 5 active projects over a 3-month period, we're devoting an appropriate amount of time to a few of them in each sprint in order to meet milestones.

Release planning is something we started doing at the beginning of this year; some clients give us a predictable monthly workload, but for most we're working on a project basis. We know how much work we can get through in a single sprint and we know how large upcoming projects and regular commitments are. We use this information to plan out the next 3 months and see early on where we might need extra resource, where we have windows to fit in new work, and how busy we're likely to be.

Two things I have noticed, which we've yet to work out: how to fit design into this process more snugly than we currently do, and how to ensure that the daily stand-up meetings are relevant when you have a team that may spend the entire sprint doing different projects.

For the former, we're looking at incremental design instead of iterative (i.e. build the skeleton for the whole app, then fill in visual elements later) - but even so, there's an up-front task to get the skeleton together.

For the latter, I'm unsure: we certainly have some clients for whom we only carry out a single activity (e.g. handset customisation), which our developers have little to do with. We've started using a burndown chart which plots design and technical work separately (as well as a unified total), though we've not noticed significantly different patterns in the chart so far - so this may not be something which is helpful in the long term.

I've certainly not covered everything we've done in this post, but I'll follow it up in a couple of months time...