How do you keep your user stories in perspective?

You gotta love those detailed user requirement specifications, that often turn into books. NOT!

I remember one of my first consulting gigs as a project manager for a traditional waterfall project that was late several months, running over budget by several digits with a very tired and deflated team with no end sight. The implementation consulting team could never seem to pass user acceptance testing (UAT).

The first thing I did to get an understanding of the problem was to ask to see the requirements document. No wonder there were issues. The document was 200 pages long. Yes, you read correctly, pages, not requirements, and the team felt like they were pushing a boulder uphill. And if you have ever read a book, you are familiar with the process of creating a picture in your head of what the words mean. Can you imagine how many different versions of the requirements each subject matter expert had – each with their own “picture” for each major area? Honestly, I never did figure that one out, but I can tell you there were way too many interpretations and each slightly, and some very, different. As you can imagine, this caused confusion and difficulty for the solution team to implement those pictures and then for the customer team to pass them through UAT.

What is a User Story?

Agile methodology brought the idea of User Stories to the table. Using short, specific user statements written on 3×5 cards or Post-it notes as the core method to record requirements was instilled as the norm. A user story is an informal, general explanation of a software feature written from the perspective of the end-user. Its purpose is to articulate how a software feature will provide value to the customer.  Extending the discussion to “what if” scenarios and “how do you know when the activity is successful” becomes an easy and productive conversation between the implementation team and the author of the user story(s).

These conversations lead naturally to the identification of complex or multiple paths of user stories. When multiple paths exist for a user story, it is also good practice to identify the urgency associated with each path during these initial conversations.  Below is a graphic from Mike Cohn video series on Writing Better User Stories which depicts multiple paths as well as multiple levels of urgency.

Agile in action

Here is a simple user story example, “As an employee, I want to be able to create an on-line expense report so that I can submit for payment approval.”

Most customers today are looking for out-of-the box solutions (OOTB) to their needs. This does not mean they do not have functional requirements for the solution you are going to deploy. Configuring a solution to the customer’s nomenclature is OOTB.  Adjusting workflows or adding a workflow is not considered customization. However, all require input from your users.

In addition to being able to decompose a user story, like the one above, you are also able to turn over the card or post-it-note and put the ‘success criteria’ on the back. As an example, for the user story above: “I know I have successfully submitted my expense report when I received a confirmation email telling me it is being processed.”

Now, let’s extend the use of user stories and the 3×5 card or post-it-note even further to include value and effort. That would be one powerful 3×5 card or post-it-note. Here, value relates to the benefit the organization will receive upon the implementation of the user story and effort is the degree of ease or difficulty to implement the story.

Below is standard user story card format which can be leveraged on any type of project.

If your requirements gathering and documentation practices do not include the use of user stories, I encourage you to include them as part of your implementation toolbox. For those of you who have your solutions, you may think about describing the solution from a user story perspective.

Christine Carter is the Global Director for Solution Partner Services & Support Enablement and has been in the PLM business for over 30 years leading projects for enterprise customers focusing on cross-organizational business process solutions and adoption management. In addition to services and support, Chris is the initiative leader for Siemens Solution Partners’ Journey to Recurring Revenue.