In pursuit of the user story purity

As Product Managers we are accustomed to answering calls for better requirements, or better-written user stories as they are known in the world of Agile software development. It’s hard to argue with the logic behind this. Scrum teams can more efficiently groom their backlogs, decompose and size user stories and ultimately come up with better fitting winning solutions that keep our customers happy and revenue flowing. 

Let’s take a look at one approach meant to raise the bar with this. A scrum team was instructed to re-visit stories on its backlog using the following WHO, WHAT, WHY and HOW framework.

·      “WHO” … this speaks about the importance of defining the end user for the requested capability.

·      “WHAT” … the approach argues it’s important to define WHAT in terms that all scrum team members understand.

·      “WHY” … if you don’t frame the WHAT in a WHY, different scrum team members will each interpret a different reason, which will lead to very different solution approaches… “As a car operator I want a cup holder in my car so that I can store my loose change in it for tolls” is different than “I want a cup holder in my car so that I can drink my beer while driving”.

·      “HOW” … should simply stay out of user story definition, i.e. left to the team.

I have to say some of the discussions around user story descriptions were quite enlightening as they helped everyone on the team better understand the need and the scope of what’s requested. On the flip side, I've also encountered what seemed like recursive looping, where the scrum team having quickly agreed on WHO, endlessly circled between WHAT and WHY in the search of ultimate answer.

Take for example this wild goose chase:

• As a middle-aged daily commute driver I want a cup holder in my car so that I keep spare change there to pay for my tolls.
• As a middle-aged daily commute driver I want easily accessible place to store change in my car so that I don't scramble at the tollbooth.
• As a middle-aged daily commute driver I want a convenient, stress-free way to pay for my tolls so that I can enjoy my ride
• As a middle-aged daily commute driver I want to enjoy my ride because the life is short

… You can see where this can lead J 

At the end of the day PO defines the requirement in the form of Agile user story, based on his/her knowledge of the market and application domain. Time boxing these discussions is all it takes to ensure your team spends just enough time to understand well enough what needs to be done to be successful.