« Much to think about | Main | Renaming Climate Change »
February 23, 2006
Telling Stories
With Melt now entering it's final iteration before we say 'right, lets see if this thing is any use' and start inflicting it on users I thought I'd take a few moments to look back over the projects history and get a feeling for what happened. The best means I have for doing this is the vast amount of documentation this project has produced.
That's chiefly because Ximon has kept minutes on every stand up meeting he's been in (almost all of them), but also because planning games and start-up sessions generate their own documents. There's also the bug tracker (which has doubled as a story tracker) and all kinds of other stuff.
For this though it's probably best if I stick to one document - the living story list, which has been kept in version control since the start of Iteration 3, which means I can get earlier versions and make comparisons.
So, what happened? Well at the start of Iteration 3 we had 113 stories and planned to do them all.
I seem to remember our very first story list had about 80 stories, but by this stage we'd taken those that looked too large and broken them down into a more reasonable list. Searching my hard-drive I've found the story list from iteration 2 when I broke the stories down into far too much granularity giving us about 140 stories - so rewriting them into a more coherent form left us with 113. To put it another way, the style (not the content) of the requirements document fluctuated dramatically from being initially too broad (80 stories) to too granular (140) to more or less right (113).
What's interesting is that at some point I spent time making the requirements less specific - not a regular occurance on a project of any kind.
Since then we've added stories and dropped stories. The current Master Story List has 147 stories, but 30 of them have been dropped as unnecessary, or at least not required for a first release. So despite being able to add stories at will our 'client' (Rolf) has been able to keep the project at almost exactly the same size as it was originally envisioned to be (assuming all stories to be equal - which they aren't). The big breakthrough came during iteration 11 when Rolf and I sat down to work out what would constitute finished for the project. By that stage the stories which hadn't been done had been consistently passed over in planning games to the point where dropping twenty or so was an easy decision to make. Even then we still wrote one new story, to cover up a gap we thought we'd created.
I'm not going to try and draw too many conclusions from this other than to note that the requirements moved around a lot, but that the scope didn't creep and the system didn't require a whole lot of change orders and price negotiations. Interesting isn't it?
Posted by Martin Lloyd at February 23, 2006 1:53 PM
Trackback Pings
TrackBack URL for this entry:
http://weblog.greenpeace.org/cgi-bin/mv/mt-tb.cgi/1169
Comments
Hi Martin,
"""
the system didn't require a whole lot of change orders and price negotiations
"""
Does this mean, that you are working fixed price, fixed time?
Radek
Posted by: Radek at February 24, 2006 2:05 PM
In contrast to the usual agile approach we're working fixed price, but time is flexible.
I think for an initial project with a new supplier fixed price is a good option, I can see the arguments that agile works much better on a time and materials / fixed time basis in general - but you have to balance the financial risk with the benefit to the project.
Posted by: Maritn at February 27, 2006 1:08 PM