Last night Mike and I traveled from Chester to London to see the Michael Vincent lecture at International Magic. It may seem like a long trip to see a lecture, especially knowing that we would be on the 7:10 train this morning to get back to work, but Michael is a wonderful lecturer and great magician. Unfortunately there were signalling problems on the lines which caused delays to our journey and resulted in us missing the first half of the lecture. The way the delays were handled led to an interesting discussion about sharing information and the correlations to delivering software.
We heard a rumour when we got on the train that there were signaling problems, but being that there was no announcement, we assumed that things were fine. We pulled out of Chester on schedule and only just before arriving in Crewe was the first announcement made. It looked as though the delays were going to be quite severe. We were about to head back to Chester when a second announcement was made: there was a train leaving now for London that would take an hour and forty minutes. We did the math and saw that we would only miss a few minutes of the lecture. We ran to the platform, found seats and soon were under way. As the train pulled out of the station, the train manager announced that due to the signaling problems they could not estimate when we would arrive in London. It was too late, we were committed to the journey!
Mike and I started discussing how this was handled and the similarities that can be drawn to delivering software. The staff were all very pleasant and apologetic, but there had been one glaring mistake that was made… they waited too long to share information with the passengers. Why was this?
Quite possibly because they made an assumption that everyone on the train had the same goal: to travel to London before the next day. If that assumption was true, then a delay of an hour, two hours or even 4 hours wouldn’t matter. We would still all make it to London and it was better than waiting until the next day. The problem is that wasn’t the goal for everyone on the train, Mike and I were traveling for the lecture. If we arrived in London too late, the journey would be of no benefit and would have cost us time and money. We often see a similar situation in software delivery, the importance of time to market. If a piece of software takes too long, it may not provide the benefits that were originally set out to achieve. The right decision may be to invest the time and money in something else.
Who is at fault here? The delivery team? The business? Both? Neither? It doesn’t really matter, the important thing is to avoid situations where decisions are made too late and by the wrong people. It is a two way street and to have the best chance of a successful engagement, all parties need to share information. Stakeholders, by sharing your true goals behind the project, the delivery team is better equipped to know what information is important to you and when you need it. Delivery team, if in doubt share information and share it early. Allow your stakeholders to make the decisions that they need to make and understand when it might not be what you hoped. In the long run the relationship will be better off for it, and there will be many successful deliveries (they may just not be what you originally planned).
One of my biggest frustrations on a project is when we have stories that capture a solution rather than a goal. Often this leads to long conversations with the business to drive out exactly what it is that should be built and hinders the creativity of the development team in finding the best solution for the problem. I’ve spent a lot of time over the last year and half thinking about this and trying out a solution to the problem and now after much encouragement from Mike & David I am finally blogging about it. This isn’t meant to be a silver bullet solution, but I hope it provokes some discussion and you find it interesting.
A few of us got talking while doing an inception early in 2009 that the ‘so that’ statement was often either repeating the requirement, was too general or was left off completely when capturing stories. This meant that we were missing the true goal of the business and lead to problems with scope and misunderstandings of what a story truly meant once we got into delivery.
Using an example of changing channels on a tv with a remote control, let’s look at some of the poorly written headlines you could have…
Headlines which repeat the requirement as the business value tend to be very difficult to prioritise because we don’t understand the benefit that they provide to the user.
As a viewer I want to change channels on the tv with my remote so that the I can use the remote to change channels.
Headlines which are vague cause debate over alternative solutions that may or may not solve the problem. Is using the remote really necessary to watch different channels?
As a viewer I want to change channels on the tv with my remote so that I can watch different channels.
Finally, in really bad cases you end up with no business value at all which are both difficult to identify alternative solutions for and to prioritise:
As a viewer I want to change channels on the tv with my remote control.
Of course there are always the times when a headline captures the true value of what the business is trying to achieve:
As a viewer I want to change channels on the tv with my remote control so that I can watch different channels without needing to be in reach of the television.
This story can be easily prioritised against other stories and alternative solutions identified, but there are still problems. The headline ends up being quite long winded and you may need to read it two or three times to grasp what we are aiming to achieve.
We played around with the idea of switching the so that and the I want but weren’t happy because it was very awkward when reading it. We got busy with the inception and the pressures of delivery overtook.
My next project was centered around helping the client learn to write good stories and develop their agile process. I had lots of time to think about what goes into a story and what is most important. My favourite question came back… how do we ensure that the true goal of the business is the most important thing captured in a headline. I came up with a potential solution, but didn’t teach it at the time because I hadn’t tried it myself. I’ve now used it successfully on my current client for almost a year and found that it has accomplished what I wanted and more.
The format that I use is:
As a (role) I want (business value) by (method/requirement)
This forces the writer to capture the value and be specific with what what the story is aiming to achieve. At first I found it quite challenging, but soon realised that the difficulty wasn’t because of the format, but that it was forcing me to have headlines which clearly stated the goal the business was trying to achieve. I wasn’t allowed to wimp out! The feedback that I have received from the developers on the team has been very positive and it has helped to ensure a common understanding with the business.Our remote control example now reads:
As a viewer I want to change channels without being in reach of the tv by using my remote control.
This states the same benefit to the viewer and solution as the ‘good’ headline above, but in a much clearer and natural statement. We can prioritise it easily and the team has the ability to think of alternative solutions. It also makes it very difficult to run into the ‘bad’ headlines from above.
Once I started using the format, I realised there was another big advantage. The business value is attached to the strongest words of the statement (‘I want’) and the method of delivering the business value is attached to the weaker word (‘By’). In the traditional I want/so that format it is the other way around. This makes a big difference in the conversations with the business when an alternative solution has been identified, but that is for a different post…
So I’ve finally created a blog account. I’ve been meaning to do it for a while and after encouragement from Mike and David to blog about my story format, I decided it was time. Of course that was two months ago. Hopefully I will have something posted soon about Stories…