If I could roll back time I would stop user stories from ever being called user stories, they simply confuse the hell out of most people I meet and I seem to spend a lot of my time trying to make sense of what it is people are actually trying to achieve with them and it’s not always what you might think.

Here’s one from a whole pile I was asked to review just the other day.

As a cell member,
I want to translate business needs, plans and service role out into performance requirements for current/future IT infrastructure,
So that demand is translated into quantifiable IT infrastructure requirements.

The others were all very similar.

Right for some context, this is a service management team and they provide release, incident, service request and change management functions, so your classic ITIL focused team.

So I went up and had a chat with the team, looked in on a couple of stand-ups, attended a planning meeting and it’s obvious that they are very keen to be working in a more agile, leaner way.

They have been used to being involved with year-long projects and acting as a stage gate along the way. The change management function that they undertake is a classic example of an obstacle to be navigated rather than a value add along the way, adding unneeded risk though cost of delay to the tail end of delivery.

And to be really fair they know that this is not a good way to work, they have seen the way that the development teams are operating, delivering much more frequently and thought that they would quite like to do something similar, become more involved on a day-to-day basis, tackle the risk earlier and more frequently.

Firstly lets applaud this, it’s fantastic that they want to work like this and they are very keen to do so big tick.

Obviously if you’re familiar with the use of user stories then you will know straight off that the story above is actually describing how they carry out a part of their function, it’s not describing what value or business benefit / impact  they are trying to deliver and for whom.

They are struggling because nobody has really told them what stories are actually used for, but as they want to be agile they see using user stories as one of the milestones on the agile journey, like doing stand-ups and having planning meetings and retrospectives, you can hear the thought process” if we tick all the boxes we will be agile”.

They simply know that a user story should to be written like this 1

As a ..
I want ..
So That ..

Without really knowing why or their purpose.

It’s a bit like trying to get involved in a game without really understanding the rules and this is key, by simply mimicking behaviours without truly understanding what the behaviours accomplish we are tying millstone for later around our necks.

It’s yet another example of people wanting follow a recipe I’m afraid, checklist driven change.

As people start to realise that DevOps is simply not just about knocking some tooling together, but about changing cultures and bringing down these kinds of barriers we are going to have to reach out and help our friends in what has been for so too long the other side of the fence.

But the good thing here is that because they have asked for help they we are in a much stronger position to move forward together, but there will be many teams that don’t reach out and ask to be helped, so how about going out to them and seeing if you can help?

1 Which isn’t actually true, so long as you can describe the Who, Why and What and are consistent in your approach then it’s all good. But they can be a good place to start as they do provide structure. The thing to remember is that you can move on from them if its right for you and you have the discipline to do so.