My First Iteration Zero
- by onefloridacoder
I recently watched a web cast that covered the idea of planning from the concept stage to the product backlog. It was the first content I had seen related to Iteration Zero and it made a lot of sense from a planning and engagement perspective where the customer is concerned. It illuminated some of the problems I’ve experienced with getting a large project of the ground. The idea behind this is to just figure out get everyone to understand what needs to be constructed and to build the initial feature set from a *very* high level. Once that happens other parts of the high level construction start to take place. You end up with a feature list that describes what the business wants the system to do, and what it potentially may (or may not) interact with. Low tech tools are used to create UI mockups that can be used as a starting point for some of the key UI pieces. Toward the end of the webcast they speaker introduced something that was new to me. He referred to it as an executable skeleton or the steel thread. The idea with this part of the webcast was to describe walking through the different mocked layers of the application. Not all layers and collaborators are involved at this stage since it’s Iteration Zero, and each layer is either hard-coded or completely mocked to provide a 35K foot view of how the different layers layers work together. So imagine two actors on each side of a layer diagram and the flow goes down from the upper left side down through a a consumer, thorough a service layer and then back up the service layer to the destination/actor. I would imagine much could be discussed moving through new/planned or existing/legacy layers, or a little of both to see what’s implied by the current high-level design. One part of the web cast has the business and design team creating the product box (think of your favorite cereal or toy box) with all of the features and even pictures laid out on the outside of the box. The notion here is that if you handed this box to someone and told them your system was inside they would have an understanding of what the system would be able to do, or the features it could provide. One of the interesting parts of the webcast was where the speaker described that he worked with a couple of groups in the same room and each group came up with a different product box – the point is that each group had a different idea of what the system was supposed to do. At this point of the project I thought that to be valuable considering my experience has been that historically this has taken longer than a week to realize that the business unit and design teams see the high level solution differently. Once my box is finished I plan on moving to the next stage of solution definition which is to plan the UI for this small application using Excel, to map out the UI elements. I’m my own customer so it feels like cheating, but taking these slow deliberate steps have already provided a few learning opportunities. So I resist the urge to load all of my user stories into my newly installed VS2010 TFS project and try to reduce or add to, the number of user stories and/or refine the high level estimates I’ve come up with so far.
