Most people who know something about Agile development will have heard that work is divided into ‘sprints’. The idea is that work is time-boxed into fixed-length periods of productivity usually over 2-4 weeks.
In pure Agile the engineers would work through the backlog of stories in the priority order agreed with the client and try and get through as much work as possible in the time available.
Yeah, and pigs are flying over Battersea
The snag with this, from the SSA point of view as a development agency, is that clients in general are not too keen on paying a fixed price (the cost of a team for X weeks) for a variable output (as much work as we can finish).
Only the most enlightened of agency clients are going to go for such a proposition and only after a rock-solid track record of achievement – indeed we do work on this basis with longer-standing clients but for getting running with a new client we need something that offers more transactional certainty (a.k.a. what do I get for my money??)
We address this in a number of ways:
- Story points – each story, or requirement, as a story point estimate and a point has a price, so the offer to the client becomes ‘we can sell you X points for £Y pounds’ (with thanks to Thoughtworks’ Vladimir Sneblic [@vsneblic] for this pithy articulation!)
- Elaboration – each story near the top of the prioritised backlog is elaborated with the client until the engineers are confident to implement and the client has told us everything they can think of about the story
- Sprint planning – once the priority stories are elaborated and story points are assigned then we discuss the priority stories with the client and right-size the sprint. This takes the form of horse-trading on the backlog until the top X stories sum to the story points that the client is buying (give or take)
- Short sprints – we limit out sprints to 2 weeks which is probably the shortest viable sprint for a team to manage properly. The story writing and the elaboration takes time prior to this but the engineering work is done over two weeks and culminates in a presentation (showcase) where we demo the completed work.
Together, these steps mean that before the engineering work starts we can offer the client a fixed deliverable for a fixed price. The client has the confidence to proceed and we have the confidence to bet on a fixed price because the deliverable is pretty clear. Only two weeks elapse between commission and delivery so everyone’s exposure is limited.
It’s also good engineering discipline to break requirements up into 2 week phases that deliver business benefit, and the client presentation is at most 2 weeks away, which keeps us all on our toes – quality is a by-product of the process.
Sometimes a client commissions a feature that looks a bit monolithic and on the face of it is hard to split into pieces that each deliver business value.
This reminds me of the old creationist argument against evolution – the proponent says ‘I don’t believe in evolution because how is part of a frog’s eye going to deliver an evolutionary benefit? An eye is only useful when fully-formed so that shows the hand of an intelligent designer’.
Well, actually part of an eye is potentially useful. If a blind frog-like creature has a mutation that creates small depressions in the top of its head, and these collect water droplets, then the sunlight filtered through the water creates the sensation of heat and the frog ‘sees’ light… the kind of light that might get dimmer as the shadow of a predator approaches. Hence the benefit of the mutation to the species: the depressions and their watery ‘lenses’ proliferate in the species.
A gross simplification no doubt but it illustrates the point that even a feature that seems all-or-nothing can often be broken into several pieces which each deliver a benefit to the client.
Eating the Elephant
In tech terms, a recent example at SSA involved a client requirement to upload XML files to an FTP location, process on a schedule, import the structured data to a relational database, recalculate some related fields with some fairly complex business rules and display progress in a UI. There were security and volume concerns which added to the complexity. This was more work than a single sprint, so how to break it up into pieces?
We’ve planned it something like this:
Sprint 1 – We implement a minimal use-case to detect a newly uploaded file, parse it, and map the data into the schema.
We create a test page for the user to search for a filename and see a basic table dump of the imported data pulled from the schema. This saves the client keying the data manually, even if the calculated fields missing – they can be calculated retrospectively.
We also have the scheduler dumping out a trace of import steps to a text file which is under the web root and accessible by the client via URL so they can get a view of the process status on demand, as it is quite long-running.
Sprint 2 – We calculate the fields after the import is finished and add these totals as outputs to the test page for verification.
Sprint 3 -We integrate the trace info and historical log into the web app UI, update navigation and set permissions so only administrators can view this new feature.
Not rocket science, but it did take some debate between client, analyst, and engineers to come up with the 3-sprint breakdown and we substantially reduce the delivery risk in doing so.