Describing value using Situation Cards

EDIT: I have since found out that Situation Cards are really similar to Social Story and Comic Book Conversations.... read more here

A while back I wrote about situation cards, which Dan Rushton and I came up to help connect developers with the reason why we were doing a particular story.

Our team works on systems where we are essentially passing messages between different services which is particularily difficult (read: boring) to demonstrate in the review. We all hate Powerpoint but looking at Fiddler or SoapUI is way more dull.

Dan's brainwave was to use the situation cards to introduce the stories we had worked on during the review. The feedback from the stakeholders was excellent and they wanted to see this happening earlier in the process.

We now include making situation cards as a part of our prep sessions. We ask the team "How would you explain the value of this story?", putting them in the place of the customer. Sometimes a single card with a one-liner can be used, usually it takes a mini dialog to explain the value:

In the example above, the value stems from additional information to help the customer pin down issues in an area of logic which is hidden from them. By handling the error differently we can show which data item is the cause allowing our customer to find the problem in the logic that drives the output from simply asking the customer which data item are showing as errors.

You might notice that it took me a lot more words to describe this than we used in the situation cards but the level of detail is essentially the same.

This does not happen by accident - a series of conversations happened before we came up with the dialog in the situation cards. The words are not accidental, we arrived at them through discussion.

The cards provide context which helps but they also act as a constraint. At a very simple level, we have very little room! Further, when we are writing them, we are thinking about how we will read these during the review - they need to be short and direct otherwise you sound like a crazy person.

We can easily refactor conversations to convey the value in as few cards as possible by changing the dialog and removing cards.

We have a series of these to represent different situations - we usually use the man on mobile to covey the customer and the man at the workstation to represent the response from the team. We also have a man in a call centre to represent interactions with our customer's customer which has come in handy too.

These become Powerpoint presentations which we then use as initial storyboards in TFS - we simply attach them as storyboards which are stored on our local network. We create them in prep and then use them when we introduce the story to the team to kick start the understanding of 'Why' we are doing this story, which is what we originally intended these cards for.

Interested to know if anyone else uses these or something similar - feel free to leave feedback if you have :)

Size (sort of) matters

Recently, I have been keeping a small set of metrics on the stories from my team. I started with simple dates so I could look at leadtimes - the time taken from when we start a story to when we deliver it.

With just these 2 dates you can do a lot! A lot of this came from looking over what was presented by Mattia Battiston at a meetup not so long ago. In particular, I was interested in his observation that there is very little correlation between story sizes and leadtime. This is something I have battled before so I was interested when my own data showed a very similar pattern:

Looking at this you could infer that a 2 point story might take as long as n 8 point story, which is hardly useful. What I missed for a while is the upper bounds across all the story sizes. We have a couple of anomalies at the top but the vast majority are within 10 days - which you should know is the length of our sprints.

That caught my interest. Although we cannot say with any sort of accuracy how long a 5 point story will take - in this example the longest was 26 days and the lowest was 4 days - we can say that 95% of 5 point stories can be delivered within 10 days or less. You can repeat a similar statement for story sizes 8 and below.

So maybe we should revise what we are expecting from our estimation by the team. What we are very good at doing is working out what can deliver within our sprint window. What we actually want to know is how many stories we can expect to be delivered if we want to use this to forecast, which is our throughput.

For me, looking at leadtimes influenced how we were working on and preparing stories. Littles Law describes how we should see a lower leadtime if we lower our WIP. We think more about how more of us can work on a single story, this often starts in prep. We open less and this lowers WIP, decreasing leadtimes.

Having a leadtime which only just fits in a sprint window means we have limited options on how to plan the work in the sprint - we have to start everything on day 1. This would mean loosing fluidity - everyone would be one a single story from beginning to end. Not many options for us at all.

Lowering leadtimes by a few days gives us some flexibility in when we can start stories. We use our story points to influence when we start on things. Larger stories might need to go first but smaller stories run in parallel so that we can deliver throughout the sprint rather than everything at the last minute, which would probably create a bottleneck with testing.

For me the sizes of stories begin to matter less and less. They serve their purpose during prep and planning and help us get to the answer: "Will this fit in our sprint?". When we see a 13 we look to break it down further since we can see it is rarely delivered in less than 10 days, which does not give us enough options. 

If we bring something in mid-sprint, we can look at the previous leadtimes and give a percentage "75% of previous 5 point stories have been completed in the time we have left" allowing us to make a commitment with some accuracy on success.

There are many more interesting things you can gleen from leadtimes and some basic spreadsheet fun, Mattia's presentation is a great place to start.