The release sprint

I had a conversation this afternoon based upon a process diagram I had put together that contained different sprint types; zero, development and release.  A debate ensued along the lines that test and quality and delivery artefacts should be produced all the time and that at the end of every development sprint there should be a shippable product; not so says I, I say "potentially shippable" product.

Herein lies the crux of the difference; the release sprint is all about taking something "potentially shippable" and making it "shippable" or "shipped".  The backlog items for a release sprint are typically all the tasks to put the code/product into production, so they can include:

• Deployment of the newly coded product into its production envrionment
• Populating the new product with production data from the previous live version
• Training / documentation handover for operational support teams
• Formal QA activities if in a regulated environment (eg FDA / FSA)
• Failover and fallback planning in case of a failed deployment

..however they should specifically not include developing any further functionality.

A rule of thumb is that a release sprint should take no longer than a single iteration of the development sprints that have been played. If this is not enough time then there are sub processes that need further tuning so that played and accepted story work is closer to "shippable" when it is "done".

My Agile day off - comparative estimation in the home

At risk of taking my work home with me I found myself planning my domestic tasks for the day yesterday in an agile manner.

My to-do list was:

• Fix chicken mesh around the vegetable beds to stop the hens eating the new plants.
• Bath the Dog
• Adjust the wheel geometry on the car
• Do the online banking and invoicing
• Tidy the workshop
• A bit of carpentry
• Help with kids homework

So I assigned a complexity to each one, taking the "bath the dog" as my 1 point starter task:

• 3 points.  Fix chicken mesh around the vegetable beds.
• 1 point.  Bath the Dog
• 3 points.  Adjust the wheel geometry on the car
• 2 points.  Do the online banking and invoicing
• 2 points.  Tidy the workshop
• 2 points.  A bit of carpentry
• 1 point.  Help with kids homework

Giving me a total of 14 points of complexity to deliver in one day, albeit with no idea what my velocity was.

From a planning perspective the task that was "needed" most was to sort out the chicken mesh around the veg' beds before the hens ate the plants; other items were less urgent so could go further down the list.

"So that, the hens don't ruin the new vegetable plants, as, a vegetable grower  I need, a way of stopping the chickens getting to the plants"

I started jobs at 10.30 (lazy start I know) and had completed the first job by 1pm. Two and a half hours to deliver 3 points !?  So at this point I was able to re-plan.  There was no way I was going to be able to do another 10 points in the afternoon - more like six. as I had four or five hours left.

Next was a bit of lunch then on to bathing the dog, followed by tidying the workshop, the banking and helping the kids with their homework - all done by about 5pm and all taking around 30 minutes per point.  My initial 3 point story had put me off the geometry job, and the carpentry wasn't important compared to other tasks and can wait till next weekend, but the rest all got done.

So what did I learn.  I'm pretty accurate at estimating against things I have done before and things similar to previous jobs (tidying a workshop is the same activity as tidying a garden for instance), and I am less accurate at estimating against work I have not done.  As it turned out, my 3 point job of fixing the chicken mesh up should have been a 5 point story. As for the geometry on the car; well looking at my velocity of 1 point per half hour is it a 1.5 hour job? I shall find out next weekend.

When I draw up the job list for my next "iteration" (day off) I shall take a learned velocity of 9 into account, although I will probably stretch for 10 or 11.