I had my first opportunity to apply some of my recent training on discovery and usability. I had a very short stint on an internal project, where I got the chance to perform some design work on a new calendar integration feature that was going to be implemented. The feature was so new, and so undefined, that I had no idea what to design!
When I finally took a step back from the problem, I remembered putting together some scenarios and stories during the Jeff Patton training. I simply wrote a little paragraph about what “Tom the Time Keeper” (I’ve never claimed that creativity was one of my strong qualities, fyi) would do with this new calendar integration; and eventually, I even came up with some ideas about how Tom would configure the calendars.
This story then morphed into a set of use cases. From these use cases, I could better determine what work actually needed to be done.
My lesson learned here is that if I write a story first, then try to design some new set of features…I can get a much better idea of what it was I needed to implement. I can immediately see how this could also benefit some of the smaller estimation efforts I’ve taken on as well. This is definitely an approach I will be repeating!
That is a great method for finding solutions before you get into the programming. I used to deal with that a lot at my last job. I would get a design and, while programming it, would find X number of issues that weren’t thought of beforehand. The story method would have helped to reduce the number of unknown situations prior to 30 hours of coding.