How To Work With Agile User Stories?

In the software industry, the word “user story” is very commonly used. Not a single day goes by when we don’t come across this word during our daily scrum meetings or sprint retrospectives discussions. Our leads and development managers talk about user stories incessantly. 

Even when software feature owners or product managers speak to their development or test team or their end customers, their entire focus of conversation is centered around the word, user stories.

The word user stories and use cases have existed in the software engineering psyche for almost 30+ years but they found their resurgence especially when the AGILE methodologies, Concepts and Sprints became the bread and butter of entire software industry.

In this article on user stories, I would like to bust some myths surrounding this concept and answer the questions that commonly plague even the most experience people of this industry.

How am I qualified to write on this topic?

While you are welcome to read about my profile in brief at the end of this article; to summarize, I have worked with top companies like Microsoft etc. in the product engineering domain conceptualizing, implementing and supporting multiple products that have been huge success [for example: Windows operating system] and some, not so successful attempts.

While it is not easy to credit the success or failure of such software products to just one concept of adequate user stories or lack of them, but they did play an important role in the final outcome of the project.

Hence, I am basing this article on my experience with user stories.

Let’s Start

As official definitions across web, user story is an informal story that depicts how a user will move from one aspect of software product to another.

And use cases are defined as informal list of actions and events that will happen once a user starts interacting with the product.

But we all know that these are textbook definitions.

Yet we all falter at one or the other time while trying to explain these two concepts to someone in our team or during an interview.

Isn’t it?

Let us try to understand the differences between these two terms and it will become easy once we all grasp the point of why these two concepts were introduced in the software engineering parlance.

Why user stories and Use Cases as concepts came into being?

As software products grew in scope and complexity, requirement management started becoming a nightmare for all product managers. It became increasingly common to ship products that did not cover 100% of requirements either due to missed requirements while documentation, or due to the fact that not all requirements were understood completely by development team.

This problem became prominent when software started being shipped as service and competition became fierce. 

Nowadays, if your software does not satisfy user requirements properly, then it is just a matter of time when a better app will take over your market share as we have seen in multiple cases in recent times.

This is the reason why products like Google search engine perform so well. Because they somehow understand what a user is looking for while searching and that shows up in its popularity.

As this reality dawned, product managers started thinking of ways to make sure customer requirements did not go missing or were implemented exactly as user would have liked to.

Things like traceability matrix etc. helped to some extent but did not solve the problem completely.

That’s when the concept of user stories and use cases started proving themselves. Someone, or may be a group of intelligent smart people thought, why not capture the requirements, at least the first cut after talking to the customer in the same way as they would have performed the action if they were working with the software as a first person.

Boom!

That’s how the concept of documenting the requirements as user stories came into being.

Hence, in simple terms, user story is a short story of a fictitious character, but with a valid role and responsibility using the software or a feature of it and getting the desired results from it.

And use cases are nothing but series of actions that the fictitious character performed with respect to the software or a feature of it with the documented desired output.

Hence, it can be summarized that user stories depict the way the end user is going to use the system and use cases are short actions with desired outputs, that when collated become a user story.

This means, it is possible to derive use cases from user stories.

Every good user story should contain following elements:

• Actor(s): Every user story should contain few actors in it with specific roles and responsibilities. Actors generally correspond to the users who are going to use the system.
• Role: Every actor of a user story has a role associated with it. The role refers to the position, responsibility of that actor within that scene. It also lists down the privileges that the actor has or does not have.
• Scenario: Every user story depicts one scenario where we briefly explain the scene setting of where the user(s) is or are, what they are supposed to do and the intended outcome or direction assigned to them.
• Storyline: This is actually the user story where we depict, how a particular actor was assigned a task and how they are going to proceed with it. It includes the interactions that they will do through the software or the functionality of the software and what desired outcome they got.
• User Satisfaction Criteria: The final section of user story contains a brief mention of why user and his stakeholders will be happy upon successful implementation of this user story.

I will give you one sample of a good user story and a bad user story. First of all, let us understand how a bad user story looks like.

Sample for bad user story:

Raj has opened the software and he used the report generation feature of the tool to generate the report. The report looks good and satisfies the purpose of his report generation. He sends this report to his manager and completes the task.

Why this is a bad user story?

This will look like a decent user story as it covers what the user wants to do; but in reality, this is a classic case of bad user story because it leaves lot of margin for error and misinterpretation by the developer during code implementation. How?
1.) Who is Raj? What privilege does he have? What access does he have to the system?  
a. These points are not clarified. Hence, the developer can interpret in his/her own way leading to wrong feature development and customer dissatisfaction or Production bugs
b. In this case, it will lead to security issues in the product itself.

2.) It does not specify as to how one should use report generation feature and where to find it on the screen. Moreover, there is no accompanying UX or sample screens for developer to know where to place this feature on the screen.

3.) It does not specify how the report looks like and which format it is in. Is it an excel based report or HTML report? If these things are not clear, it might leave a lot of margin for error for the developer during development phase.

There are many more other problems with the above user story. 

Now let us check a sample for good user story.

Sample for good user story:

Raj, is a system admin in the XYZ company. He has the admin access to the report generation server and is the only person to have this access. He gets an email request from his manager for report generation in excel format for the period between 1st Jan to 31st March and is supposed to generate this report in 15 minutes and send it to him.

Raj opens the software and clicks on the “report generation” tab on the top header of the screen [as shown in the sample UI] and chooses the required fields such as time period for the report, format of the report and clicks on generate.

The report is generated in 1 minute and is available for download and save or directly open. Raj saves it on his desktop and opens it. Verifies the report in his MS Office 2016 suite and emails it to his manager.

He was able to complete this task in less than 15 minutes and hence, he and his manager both are happy with this report generation feature of this software.

Why is this a good user story?

• It clearly explains Raj’s role in the system and mentions the privileges that he should have for this activity.
• It also clarifies who else has this privilege. In this case, no one apart from Raj has this access.
• User story is clear in the performance aspect of the feature of this software in terms of time constraints.
• It also shows the sample screen where developer will know how the button should look like, where it should be placed on screen etc.
• The user story is clear on what all fields are to be filled in by Raj before generating the report
• The options that should be presented to the user after report generation are also mentioned explicitly in the user story
• And most important of all, the user story clearly explains why the user and his stakeholder, Raj and his manager in this case, are happy by the usage of this feature. That is known as user satisfaction criteria.

What additional information should be provided along with user story?

A functional specification document is the one that acts like a holy guide to the development lead and his team for generation of completely flawless development specification document. However, providing following information along with user story does add credit to your user stories in addition to the ones mentioned above. We will take the same report generation example.

1.) List down all possible formats of the report that should be supported by this feature
a. Each format will become a separate use case within above described user story.

2.) List down the range of actions supported by the feature of that software. That will be a separate user story.
a. And each range will become a unique use case within that user story.

3.)    Provide all the UX assets i.e. samples for UI to be used by the developer.
a.This ensures consistency of the UI

This leads to another set of questions:

1.) How to know which aspects of the feature should become a separate user story 
2.) How to know which aspects of a user story should become a use case within a particular user story.
Let us discuss the first question here. I will cover second question in my future post about use cases.

Boost your career with project management certification prep. Unleash your potential and lead with confidence. Begin your journey now!

How to know which aspect of a functionality should be a separate user story or not?

The golden principle that I generally follow to determine this is:

 All the actions related to one aspect of the feature [for example: report generation in prescribed format] will be one user story
Working with that same example of report generation feature, if we assume that the report generation feature should have following aspects/benefits as desired by our end customers:

1.) The report generation will take less than 15 minutes
2.) The report can be generated for multiple time periods and are customizable by the user
3.) The feature will support 5 different report format types such as excel, word, HTML, notepad, CSV
4.) Only authorized person will be able to generate the report

Then I will make 4 user stories out of these.

1.) User story 1: This will tell the story of how the user [Raj I this case, will use this feature to generate report in different formats as per requirement
2.) User Story 2: Here I will showcase, how user should have access to system before using this feature and what happens if the user does not have access.
3.) User story 3: I will focus on the timing aspects of the feature here.
4.) User story 4: I will work with different supported time ranges and what will happen in different combinations including the boundary cases.
5.) User story 5: Here I will focus on how the user will interact with other controls of this feature such as cancel button etc.

And finally, out of these 5 stories, I will generate N number of use cases to provide thoroughness in my user specification document; leading to complete clarity for my development team to generate their design.

As a golden principle based on my experience- 

A user story is a way to tell the development team on how you expect the user to perform the actions and what is allowed, and what is beyond the scope.
User stories lead to use cases; use cases lead to user requirements and user requirements lead to development specifications that can finally be broken into sprints and delivered across project milestones.