Here at Caplin we use and are constantly evaluating Agile practices and techniques that make software development and maintenance as efficient as possible. In particular to the practice of BDD, which ‘utilises stories as it’s basic unit of functionality’ according to Dan North (http://dannorth.net/whats-in-a-story/).
Even if there is an existing body of requirements assets available at the inception of a customer engagement the first challenge is to ‘storify’ those assets. That is to assess each of the assets and ensure that it meets both Dan North’s assessment of what makes a good story, and also so that it passes our own 4 criteria for a good story:
Passing on all of these criteria ensures that stories are suitably sized and that there is enough information to add the stories to an initial backlog for categorisation. This categorisation process will then provide the basis for dividing the stories up into groups as iterations and releases.
About 5 years ago two of our number who regularly manage customer engagements were at a conference where Jeff Patton was speaking. He was describing Story Maps (http://www.agileproductdesign.com/writing/how_you_slice_it.pdf) and the thoughts that the talk elicited were that this was a ‘brilliant’ idea, and something that would really help with the process of categorising and prioritising the initial story backlog produced at the inception stage of a project.
Since that time we have regularly used Story Maps as part of the Inception phase to facilitate categorising the initial stories and producing the iteration and release plans. Stories can be arranged into functional areas, and then ranked by criticality. This allows a ‘walking skeleton’ (http://alistair.cockburn.us/Walking+skeleton) to be built, providing a ‘steel thread’ or ‘barebones’ implementation to be built in the earliest iteration. Then the ribs can be fleshed out and slowly the application will be built around this skeleton.
In part 2 we’ll look at some issues we have had with using Story Maps.