User Stories 101 – The story so far

When I began in project management, before the evolution of agile, we used waterfall methods. In practice, this meant that we started by doing our analysis, then our planning. When we completed planning, we progressed to building our product. The problem was, that we were making all our decisions up front, when we knew the least about what we wanted to do. (BTW: I just posted a blog about Waterfall on the site. Why not check it out!)

Along came Agile, which looked at this process and decided that we should improve. The agile manifesto puts it front and center by stating “we respond to change over following a plan”. And User stories are one of the primary ways that we can shift to this more agile mindset.

Traditionally, in enterprises around the world, someone had an idea, and if approved, it was handed over to The Analyst. The Analyst then  took ownership of designing the product. It was this person who talked to all parties. 

Note: in most of the enterprises that I worked with, we did not consult the user or the customer, mostly just the internal stakeholders. 

They analysed what was needed and progressed to design a document, The Specification, which, when signed off, became our holy grail. The developers would recive this docusment and build exactly what it set out, no more, and no less. And as I said, the specification was completed before any work started. I am being overly simplistic here, but you catch my drift. 

Let me be honest, this is an okay way to build a new product. Okay, but not great.

Being critical about this specification led  approach, I could point many flaws but the main two would be in that many of the people who should input into the design have yet to be engaged (developers, users etc), while others are only partly engaged (the business team). The second is point is as mentioned earlier, we are making all our decisions up front and locking them down when we had the least amount of knowledge about our customers, our users, our product, our abilities etc

User Stories are a placeholder for a conversation
User Stories are a placeholder for a conversation

So, agile needed new ways to define the product and User Stories are one of these methods.

Let me give you a simple comparison to start us off. 

Waterfall: Mum says to her twelve year old little boy, “can you go to Mr Jone’s shop and buy me a litre of Brand A milk, costing one dollar”.

Agile:  Mum says to her twelve year old boy, “can you get me at least a litre of the best value milk”.

Can you see the difference between the two requests?

Let’s fast forward to the child in the shop. With the Waterfall request,  the child arrives in the shop and could find that:

  • The brand is not available?
  • They only have 2 litre cartons
  • A similar brand is cheaper

But the specification was very specific, even  in the light of an evolving and realworld situation.

If they could just change the request slightly, they would satisfy the customer (ie Mum) with a better solution!

So, can you spot how the agile request is much more high level. It does not specifiy the shop, nor the brand, as these are not usually important. But the price is important, and agile puts more responsibility on the child, who needs to think on their feet and make good decisions along the way. (I know, I know, let’s assume the 12 year old is mature for their age!!)

Let’s dig a little deeper. There is a well known article written by Ron Jeffries that describes the “3C’s”. A Card, Conversation and the confirmation, 

If you are involved in agile, you must be aware of the supreme status of the humble  post-it note. This is the Card. Each card represents one user story. It is a token representing the requirement. We usually visualise them on the wall and follow the journey of each post-it to completion.

The Conversation represents the fact that we continually grow the requirement by talking, debating, exchanging views and opinions. We stand around and  talk about it together as it goes on its journey from a kernal of an idea to a fully developed requirement and is finally delivered. This user stories is permitted to continue to evolve, up to the moment that we pick it up to start to work on it. This could be in the first day of delivery or the last day of a one year project. This replaces the waterfall method where the analyst asks everyone for their thoughts,documents it and we set it in stone before the development even begins.

The third C is the Confirmation. This centres around the criteria that we all agree that will define this requirment as complete, finished, done! In agile, we call them the acceptance criteria. In our example above, a few criteria could be

  1. The price needs to be $1 or less
  2. The milk needs to be 1 litre or more
  3. It needs to be full fat.

These give our 12 year old boy the flexibility and the trust to to be creative but with the necessary guidance. We tell them WHAT we want, they must decide HOW to do it!

To Be Continued

Leave A Comment

Your email address will not be published. Required fields are marked *