Having posted about Requirement Packs the other day, I noticed this post on Brian Marick’s blog, at the time I read the PDF that he supplies with some interest, Esther Derby then linked through to Brian’s post and caused me to give it some further consideration.
During the skunkworks project that I ran before Christmas I tried to get the steering group to deliver their requirements to us in a story like manner and largely in line with the templates that I mention in my previous post. What the Steering Group ended up delivering to us were what I would consider Epics (I have started reading Mike Cohn’s book User Stories Applied: For Agile Software Development which discusses his perception of an Epic versus a Story but neglected to bring it with me on this trip.), given the time constraints the Delivery Team ended up having to take decisions during the time that they used to break the Epics down in to stories, thankfully it worked well for us and the steering group were relatively content to allow us to continue to operate in that manner.
I had a discussion with a couple of colleagues prior to my departure in which we were discussing how we approach projects. One of them stated that she thought that we should be more mindful of who the customer is when we are beginning a project and that we should consider how we engage with them to draw requirements and run the project. I agree with this and I think there are a couple of points to note.
The use of the word customer is interesting, whether it is just my perception I am not sure but I think we sometimes neglect to remember that we are a customer facing division and that business effectively justify our existance by usage. Furthermore, I think it’s important that we understand how best to engage with our customers, I would suggest that one of the issues that our customers have with us is that we go through a requirements gathering phase and then produce a large document with the requirements as we understand them at the time and then expect them to sign off on that document.
Perhaps Stories could be a useful tool on the road to overcoming both of these problems. In fact I noticed this post on Digg the other day which mentions that the Mozilla Developers and Drivers behind Firefox 3. In it they mention a Product Requirements Document which interests me further solely because of the word product. When I worked on the Skunkworks project it was very easy for me to implement an Agile approach as we were clearly delivering a product to market, the majority of the projects that we currently undertake as a division don’t necessarily view what is being delivered as a product, perhaps this is something that we also need to give consideration to to enable people to understand the Agile Concepts in books a little more.
I am aware that there are other methods such as UCD and BDD for gathering requirements, the latter of which I found an interesting post relating to how stories are used within the other day. It will be interesting to see how Dan’s document evolves but I think it gives a great explanation about the use of Stories already.
As I mentioned in the Requirements Pack post the other day, I think that each of the future Skunkworks projects should have a 2 page document outlining the perceived business value and the headline requirements for the project, I wonder now if it should take the form of a Product Requirements Document, I googled for a template and found a number of alternatives, maybe we should even consider this as a document to replace / support some of existing documentation.