Interesting User Stories

I recently held a coaching session with one of my colleagues around the topic of User Stories. There are a lot of articles and books written on the subject, each with the basic structure of:

As a…

I want…

So….

User stories are something that I’ve seen myself and others struggle with. In the past I’ve often put ‘get better at writing user stories’ on my personal development board as I’ve always felt they could be better. I’ve also read a lot on the subject in an attempt to get better but for one reason or another it hasn’t stuck with me.

During this coaching session, I asked for an example of a user story that we could potentially improve on. The story followed a familiar format:

As a user

I want a search field

So I can find a report

At this point I realised we didn’t have enough context or information to jump straight into improving this story. We had to take a step back and look at what we were trying to achieve with the story first. I’ve recently been thinking a lot about the ‘why’. Why we do things, why we believe, why we change and many more.

I often like to take the ideas of software and apply it to something more tangible. For this session we came up with the idea of ‘Clothes’. This became the context or domain in which our character (person, user) was set. This became our product.

Our next step was to identify the ‘Why’. Why might this character need our product? For example:

  • To not be naked
  • To keep warm
  • To be fashionable
  • To feel good

Once we had this information, we then thought about the type of person our character might be. Who are they? What is their context? We then began experimenting with how we might structure a user story using this information:

As a person who wants to leave the house

I want something to cover my body

So I won’t be naked in public

Or

As a person who lives in a cold climate

I want something that will prevent me from becoming too cold

So I can keep warm

These were ok, but we could do better. By changing the person’s context and their why, our stories could become more specific..

As a person who is travelling to Antarctica

I want protection from the cold

So that I can survive -20 degree Celsius temperatures

None of these stories gave a solution. The ‘How’ could come later. By structuring our stories in this way, we allowed room for multiple solutions to a problem rather than narrowing our thoughts into one area. If we take the last user story above and provide a solution, all of a sudden our options for how is significantly narrowed:

As a person who is travelling to Antarctica

I want a survival coat

So that I can survive – 20 degree Celsius temperatures

This seemingly innocent structure is limiting our ability to innovate.

Going back to our original story, we thought about how we could make it better by following a new structure

(Who) As a <character> who…

(What) I want <need>

(Why) So <my need can be satisfied>

Our original story rewritten looked like:

As an accountant who wants to file my client’s GST report at the end of the financial year

I want to find clients who have outstanding GST reports

So I don’t miss the deadline for GST returns and I avoid any penalties

This poses the question, if user stories are supposed to tell a story, do you want to tell a boring story with ambiguity or an interesting story with meaning?

The Evolution of UAT

User Acceptance Testing. It’s a phase of testing that’s bothered me for a while. Not because I think it’s a waste of time, in fact, quite the opposite. It’s bothered me because I think it hasn’t been given the care, attention and expertise it deserves.

The intent of UAT has always been a noble one. We wanted our users to accept our product and accept what we had built. The way we went about proving that acceptance though was deeply flawed. The process looked a little like this:

Step 1: Find some users or, if users aren’t available, you can do it yourself

Step 2: Write a script for the user which outlines exactly how they should test the system step by step in predefined workflows

Step 3: Get the user to complete each step putting a ‘Pass’ mark next to each one

Step 4: Write any questions or confusion from the users down as ‘training issues’ (If you’re testing it yourself, you probably won’t have any questions because you’ve already tested it in the system and integration test phases and you know it works. Besides, you’re not the one who has to use it on a daily basis anyway)

The problem with this approach is that it seeks to validate the product even if it invalidates the experience of the person using it. At this point it’s not really about your user accepting your product, it’s about your product functionally working when put in front of an end user.

How do we solve this problem?

Firstly we need to understand our users. We need to understand their needs, their activities and the context in which they are performing those activities. By doing this we change the meaning of UAT into a list of things our users will accept, things that will delight our customers once we’re done. Once the feature goes live, User Confirmation Testing can commence. Confirmation testing allows us to measure the degree to which we were successful against our initial assumptions, hypotheses and insights. Both qualitative measures such as customer feedback and quantitative measures through the use of data analytics can help us to identify what our users have accepted and what they have rejected. This gives us the opportunity to research, build, monitor, iterate and improve.  

UAT done in accordance with this new meaning is hard. It involves a lot of effort, time, understanding and empathy. Not all of the “defects” we find during the first UAT phase will be ironed out so confirmation testing shows us where we’ve been successful and where we need to iterate and improve. This pushes testing to the start of the development lifecycle and helps to prevent usability flaws in our finished product. Perhaps, most importantly, it provides the opportunity to test before the code is written, as the code is being written and after the code has been deployed adding value at each of these stages.

At a time where people have so much choice and greater expectations that software should be engaging and intuitive, understanding who we are building software for can help us to meet those expectations. It is no longer good enough to be happy with “work arounds” or “at least they can still <insert anything unrelated to the thing they can’t, but really want to do>” attitudes towards software development. Focusing on what our customers value and delivering the things that will really make a difference give us a head start on any competitors in our market.

Every time a new idea for a feature comes into a team we can all strive to understand who we are building it for and what problems this change will solve. If we can’t answer these two questions, it’s time to put the deerstalker on and seek out the answers!