User Stories

Definition:

A user story is a part of an Agile software development approach to acquire the details of a requirement from an end-user’s point of view. The user story specifies what type of user you are, what you want and the reason behind it. Simply put, a user story helps create a simple and short description of a requirement told from the user’s perspective.

What are User Stories?

Let us first understand why it is important to understand product features.

The product attributes play a vital role in the evolution of software development process. These are the attributes that the end-user finally likes to apply in the end product. These are known as ‘Specifications’ or ‘Requirements’ in the Agile development terminology. The success of a project relies on understanding the end-user requirements exactly and then applying accordingly in the end product. Therefore, the product features or requirements need to be completely known to the project development team.

Back in 1999, Kent Beck coined a term called “User Stories” for the product attributes. He explained that the word User Story is best described from a customer’s point of view, what he or she wants to have instead of what system can do for him/her. Hence, the vision had a change from product to end-user finally and User Stories became the real standards for Requirements in all Agile processes.

Originally, Agile user stories were meant to be very short and simple to write on sticky notes or index cards. They were fixed on tables or walls to simplify their planning and discussions. Therefore, they actively shifted the target from writing about features to explaining them.

In reality, these explanations are more important than whatever story is written.

In Agile projects, the Product Backlog includes all the user stories. In the Sprint Planning Meeting, these user stories are pulled into the Sprint Backlog based on the priority.

The concept of Estimation is also built on user stories, and the size of the product is determined from Story Points

Structure of User Stories:

The Scrum teams generally follow a simple approach for a user story:

As a < type of user >, I want < some goal > so that < some reason >.

Another approach includes:

As a <user type>, I want <some goal> because <why>.

So what exactly is the purpose of ‘user stories’?

“Ron Jeffries”- offers a very simple and effective way to explain user stories. He illustrates them as the three Cs: card, conversation, and confirmation.

Card:

The idea of keeping card and writing stories is quite easy. We have index cards or sticky notes with a size of 3 × 5-inch to write user stories.

A structure of user stories can be prepared to define what type of users they are, what they want to achieve, and what is the reason behind the goal.

The main intention behind writing in this card doesn’t include all the information that builds the requirement. In reality, we use small cards to occupy less space with fewer lines that summarize the customer requirement. It is a place to contain more detailed conversations with the stakeholders, development team, and product owner.

Conversation:

The user stories are all about the conversations!

The detailed end-user requirements are communicated to all the team members, stakeholders, and the product owner.

The conversation doesn’t happen only for a one-time event. It has to be done in all the iterations with a continuous process for the entire project cycle. The user stories should have a conversation from the start to the end of the project. Finally, the continuous conversations of the user story have to be completed only after being-

1. Designed,
2. Built and developed, and
3. Tested during the iteration.

The main advantage of user stories is that they deviate the focus away from the continuous writing of stories to effective conversations. These conversations provide easy means to change information and combine them to make sure that the correct requirements are managed and understood by everyone. These conversations can be verbal or augmented with documents. These may improve if we have a UI sketch or an elaboration of business rules that get written down.

User stories are very simple to begin for extracting the initial nature of what is to be required. They also provide an indication to discuss the detailed requirements when suitable.

Confirmation:

Regardless of how much of documentation or discussion we generate, we need to confirm ‘what’ is to be completed. The key aspects of user story, therefore, include confirmation as the third C that we actually need as the element for acceptance test.

Let us quickly talk about the relevance of acceptance test and acceptance criteria in this context.

We have one side card with a line of story descriptions called “front of the card”. The other side of the card has “satisfactory conditions”, which is nothing but acceptance.

These are basically the acceptance criteria that resolve the doubts in a proper way. User stories are used by the development team in order to understand what needs to be built and tested by the product owner. The product owner is the responsible person to approve the implemented User story to his satisfaction.

Members in a team who are not having any idea or experience often want to try using spreadsheets that show mathematical calculations, use cases, outline of proposed window blueprint, and also multiple page documents appearing like conventional requirements. These might be useful in many cases. But in the past few years, we never have found this type of document to be perfect.

Both the stories and acceptance tests are implemented by the programmers.

At the end of each Sprint, when the story is completed, the development team shows the stakeholders that the associated story is completed successfully in conformance with the acceptance tests.

If we were using a specific tool like FitNesse or Fit, we would easily define these kinds of tests in the table shown above. It shows examples of different sizes of files and also shows whether they are valid or not.

By evolving with these specific examples, we can manage the creation of a story and refinement process.we can also have the acceptance tests (automated) available for every story.

Level of Detail:

User stories are one of the best channels to carry the items of stakeholder or user ideas through the Scrum value-creation stream. Although, if we are comfortable with a single user story size, it will be complicated to do a higher-level planning and receive the benefits of continuous refinement.

At the Sprint level, the stories are too numerous and too small to support release planning and higher-level product. In these levels, we require fewer, more abstract items, and less detailed stories. Else, we will be stuck with irrelevant details.

We will never use epic in a Sprint for development because it is difficult and not explained in a detailed way. Alternatively, epic stands as the best placeholder for heavy collection with detailed stories to be created at a suitable time.

The stories that are represented in size, are usually in the order of weeks and are therefore too large for a single iteration. A few teams will call these “features”.

The chunks of user stories are generally referred to as ‘stories’. To ignore the confusion with features, epics, or other larger items, some of them are called ‘stories’ or ‘sprint table stories’. Either way, these are implementable stories to specify that they represent in the order of days in size and thus a small size is enough to get placed into an iteration and get executed.

INVEST:

How do we know whether the written stories are good user stories or not? Herein, the INVEST concept comes into play.

We shall see why it is important in the Scrum context.

Bill Wake is the creator of the INVEST concept. He proposed six criteria to represent the quality of the user stories. “INVEST” is an acronym that helps to memorize a broadly accepted set of criteria, or checklist, to estimate the quality of a user story. If any one of the user stories fails to meet the criteria, then the team has to rework on it, even they have to rewrite the old user story before writing the new story.

A good user story should enclose the following concepts:

1. "I" Independent (of all others)
2. "N" Negotiable (not to a particular contract for features)
3. "V" Valuable (or vertical)
4. "E" Estimable (for a good approximation)
5. "S" Small (so as to fit within a sprint)
6. "T" Testable (in principle, even if there isn't a test for it yet)

Let's have a brief explanation of each criterion.

• Independent

User stories should be independent or at least they should be loosely coupled with other stories. User stories that show a high level of interdependence result in complicated estimations, planning, and prioritization. If we are thinking from a point of independence, it is often simple to think of “independent order”. In other words, user stories can be operated in any order.

So why does this criterion play an important role? Because it provides valid priorities to each of the user stories.

When we apply the independent criteria, the focus is not to remove all the dependencies, but rather, writing user stories in a manner that deprecate dependencies.

• Negotiable

The user story details should also be in negotiable. The user stories are not written in the contract, but it is a call to the conversation. Instead, these stories hold the place for the conversations where the actual details will be transferable. Good user stories will clearly seize the essence of what type of functionality the business people want and why it is needed.

However, they quit the place for the stakeholders, development team, and the product owner to negotiate their details on the grounds of technical, budget constraints, and functional aspects. The focus is to meet the stakeholders’ needs, but not generating something unusable to the concept of user story if doing that it is incomplete.

• Valuable

User stories should be valuable to a user, stakeholder or customer, or both. The customers will selectively choose and keep their fund for the product. Customers actually require the usage of the product. If a user story is not beneficial for the customer or user, it is no more a part of the product backlog. We can’t say which user story is valid and valuable for the user or customer. If any of the user stories is not valuable to the user or stakeholder, then that story should be built in the right way to be usable or could just be rejected.

Probably, user stories in the product backlog are being prioritized according to the market value, so it has to be in a clear process. If the user story has functional requirements, then it should be present in a business value else if it is a technical story, then it should be represented in non-functional improvements or architectural. It has been stated that while in practice, most of the technical user stories are not listed in the product backlog.

Finally, consider the clause “<value>” of the user story. The reason behind it is to deliver the exact value by finishing the story.

• Estimable

A story has to be sized or estimated by the Scrum team so that it could be appropriately prioritized to design, develop, build, and test them accordingly. The word estimation helps to indicate the size of the user story and therefore knowing the effort and value of the user stories. Obviously, bigger stories need a lot of strain and also require more funds to develop than the smaller ones.

If we know the size of a story, it gives actionable information that is required by the Scrum team. For example, the product owner has to know the cost of a user story to estimate the final priority in the backlog list. On the other hand, the Scrum team has to measure the size of the user story and determine if any more refinement is required. If they plan to work on a large user story, they need to split it into a number of smaller stories.

• Small

Obviously, user stories are made into smaller chunks, but how can they be further split into smaller units? The solution depends on the methodology used by the Scrum team members.

Let’s say we have an epic-size story that we aren’t planning to work on for another year. Arguably that story is sized appropriately for when we plan to work on it. In fact, if we spent time today breaking that epic down into a collection of smaller stories, it could easily be a complete waste of our time.

Let us consider, we are not planning to work on epic story size for the next one year. Presumably, the story is sized appropriately for the time the team plans to work on it. In reality, we spend more time splitting the epics into smaller stories, thereby it is a major waste of time. Rather, if we want to work on a user story for the coming iteration, it needs to be sized properly.

• Testable

Each and every user story requires to fulfil the testable criteria in order to be considered “done”. In reality, we think of “testable” as nothing but the acceptance criteria.

We can’t imagine any work done without some testable criteria. Else, how could we possibly know that the user story is completed at the end of the iteration? And also, making use of these tests regularly offers the details of user stories. They might be useful before the Scrum team calculates the story. It might not always be necessary for every story to get tested. So, by thinking in this way, it improves teamwork, constructs good quality by moving towards Quality Assurance upward in the process, and allowing for satisfying conditions(acceptance criteria).

If the Scrum team and the product owner work together to INVEST in making good user stories, the wisdom line of working together will be much shorter. INVEST helps to improve the good habits by eliminating some of the impediments of user stories like dependencies, being too large, difficult to test, etc. Make time to INVEST in user stories and view the drastic changes in productivity.