Release planning at SynthaSite

As I mentioned a few weeks back, the SynthaSite team were taking a few days break from the usual schedule to come up with a shared consistent view of what it is we are building and how we want to build it.

It was probably the last time we'll ever get so much dedicated time to work together as a team, as the process of some of us moving to San Francisco has begun.  I'm not sure everyone appreciated that (I don't think I did), but I was impressed at the results of our process of hiring the best and most passionate - the end result was something we can be proud of.

We first went back to school to learn the theory of our Agile process (initially vaguely Scrum, but becoming more Scrum-like, especially after this discussion), and applied those theories to made-up projects after breaking up into smaller teams.

After dreaming up products (ours, the "Pocket Rocket", was a jetpack, although it seems it is either a vibrator or moped in real life), we came up with a product vision for our projects using a common elevator pitch formulation - the target market, the problem they have, what the product is, who else is trying to solve the problem and why you're better than they are.

The Pocket Rocket had two markets - the jetsetters (that one never gets old) and the military.  It's for getting from one place to another on your own schedule - unconstrained by traffic, surfaces, and so forth.  (The other team had a much more realistic product.)

We then practised creating user stories for our products - in the form:

As a stakeholder-type I would like some feature so that some reason

After that, we explored two methods of prioritisation - the Kano model and relative weighting.  The Kano model primarily allows you to determine what class of value a particular story falls in - based on the effect caused on your user base if you don't do it, if you do it, or if you partially do it.  Relative weighting allows you to assign relative weighting in terms of both value of the feature, and the cost of the feature.  Using these, you can get numbers out on what the best value for cost features are.  Neither is useful in isolation, but in combination can allow you to develop the features your user base demands rather than simply wants, and capitalise on those things that would be quick wins.

Finally, we played some planning poker - we each got a set of cards (0, 1, 2, 3, 5, 8, 13, 20, 40, 100 - the above set is a Crisp Planning Poker deck), and as each story came around for estimation, we showed the card that represented our guess at the effort involved in doing the work, relative to other tasks.

After that, and a break, we set about doing it again for real on SynthaSite (everything - the site builder, the web site, tutorials, support, our development and staging environments, &c.).  It was a lot harder initially to come up with proper user stories and to estimate, since it was a lot less abstract than our example projects, and we were a lot more passionate about the real project.  But, after a while, we got into a rhythm, and we came up with something that both looked and is really impressive at the end of the day: