Agile: Is there always a user in your user story?

Agile, User Stories - go together like <insert favourite cliche here> and for user facing (typically GUI) interactions, they work very well.

My definition of a user story (many others are available) goes like this:

AS <A user or user role>
I WANT TO / NEED TO BE ABLE TO <Do something / Perform a function>
SO THAT I CAN <Achieve a result>

Simple: WHO, WHAT, WHY (you can also add WHEN if needed, but avoid HOW)

An example would be:

AS a customer service agent
I NEED TO BE ABLE TO Update a customer's address
SO THAT I CAN keep the customer's data correct when it changes

The most common omission is the WHY: In my book, if you can't write out the why, then why is the user story in the backlog anyway?

The second most common is the WHO. As in the following 'User Story'

'We must be able to keep the customer's address current' or (even worse in my opinion)
'The system must . .'

What's wrong with these?

For the first one, it misses the role or person who will do it. This is more important than many people realise. It can show up most often in the end-of-sprint playback and be missed by the entire team!

If the playback is done by one of the developers and the dialog goes something like this: "Here's the address change screen, (click, click, scroll, launch-of-developer-tooling) and you'd click here then overwrite the database contents here . . ." you've found your problem.

What they've actually built is this:

AS a developer
I WANT TO Demonstrate the updating of the customer database
SO THAT I CAN get my story points, mark the story done and move onto the next iteration

Compare and contrast with the actual user story above. Why isn't the customer service agent doing the playback? Because they haven't got a logon? Because they haven't been trained? Because the code is isolated and doesn't have dependencies (like a link to the LDAP where their userid is stored). In that case, in my opinion, you haven't done the user story because the user cannot actually do what they stated they wanted to do in the user story.

But hold on, you say, this will all be sorted out in PROD, won't it? We're still in DEV! We'll fix that before go-live!

Will you? When? And who is going to do it? You've claimed your story points, your velocity has been updated and as a UK politician famously wrote 'There's no money left!'

I talked to a Business Analyst who is also responsible for training users and she asked a very good question: "Where in agile does my training material get written? All this 'don't document' in agile means I can't write a manual / make a video / build help screens."

At this point, I referred her back to the idea of the user story - and there are two options.

If the user requires a training course, documentation and a trial period before they can 'update the customer details', then that's what they need. That's their user story. Part of what seems simple may seem like it's turning into an epic, but that user cannot achieve their results without the resources they need. If the user can't use it, why write it? So, you need the trainer as part of the agile team (in the same way as you need developers and testers) and the story is only 'done' when you have all of the materials ready to go.

Alternatively, you could say

AS the training manager
I NEED TO BE ABLE TO provide a video / written / CBT training course for the end-users
SO THAT I CAN enable new users who were not part of the project originally to learn how to use the system

And yes, this needs to go in your backlog.

The second 'user' story form I have issues with is this sort of thing:

"The system must log all entries and exits of every call to the mainframe"
"The system must audit all entries into the general ledger table"

Really? Why? And more importantly 'WHO CARES?', I'm not being facetious here, but asking 'who cares?' (similar to the 'so what?' technique) really drives out why the story is here in the first place. If no-one who is a user of the system cares whether is does it or not, then why do it?

The two examples above are typical 'no-user requirements' that are so often documented in a 'different way' but I encourage you to think about who actually cares that they are done. (Try omitting them from the backlog and see who screams!) Once you have that person, you have your user story.

For example:

AS the technical support person
I NEED TO BE ABLE TO see every entry and exit of every call to the mainframe
SO THAT I CAN answer the question "Did transaction nnn get sent to the mainframe?' when debugging a live incident at 2am.

AS the person in the company who is being audited for a legal investigation
I NEED TO BE ABLE TO search for and find all transactions involving company nnnn and prove that they could not have been altered after they were performed
SO THAT I CAN avoid losing my job or even going to jail!

See how that focusses the mind? Also see how this builds your test cases? If your playback developer says 'look, here is the audit text file we built - you can see it in this text editor', is that the same as someone desperately searching 10TB of unstructured data with 'update any' in the file permissions and worrying about their liberty?

So to some up (and this is just my 2c as per usual!)

• If your user story can't explain the 'WHY', then 'As a product owner, I want to relegate all stories without reasons to lowest priority so that I can spend my budget on ones that add value'

• If your user (not you!) can't do what they wanted to do in their user story, you haven't completed the story. If they need training or help text, that's what you need to give them.

• If there isn't a user in your user story, who cares if you do it or not? And who's going to say 'done'?