Published on Aug 22,2017
665 Views
Email Post

User story that came from Extreme Programming moves away from writing requirements and focuses more on talking. They are used to capture the requirements in multiple implementations of Agile, including Scrum.

According to Wikipedia, “A user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function”

Before we talk about user-story further, it’s important to understand why people needed to shift from big bulky requirement documents to something called user-story.

Background

In waterfall, requirements are captured in big documents. Why? The team works in silos.

Silos are all about working as independent departments within the team. No more collaboration towards holistic goal. The focus is to complete their individual targets and not overall project goals. So for a tester in waterfall, the goal is to find as many bugs as he/she can. The goal is no more helping the developers build quality within the product from day one. Similarly, developers focus on completing their coding and leave quality to testers.

In waterfall, development team members come onboard at different point of time. For instance, testing team members come onboard only when development is over. As testing team members may not be around at the time the requirement got written or modified, the only way to know the requirements and the changes within was through the Functional Specs document.

Any change in the requirements have big repercussions as that could impact whole cycle of design, coding, testing and development over a course of time. It was also implicit that any change at any point of time had to be reflected in all documents, including Functional Specs.

Move to Agile and team consists of cross-functional team members (i.e. developers, designers, devOps and testers) working together to build a small functionality end-to-end that provides business value to the end user. Alll cross-functional team members communicate face-to-face and clarify their doubts. As soon as they arrive with fellow team members, they don’t need to rely on big bulky documents anymore. They create documents which serves purpose in the maintenance phase.

With this background, let’s understand the concept of user-story.

What is a user-story?

User-stories are written from end-user’s perspective. They typically follow the following templates:

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

OR

As a <who?>, I want <what?> so that <why?>

One should be able to write a user-story in 4×6 index card. They have to be small enough to explain the intent but details could be finalized after discussions within the team and product owner.

Example User Story

User stories can be written in varying details. Large user-stories are called epics or features.

Here’s an example of Epic written for email client:

  • As a user I would like to have search functionality for my emails so that I don’t have to find the related email manually

Team should work on smaller user-story which could be finished within half sprint by a pair of developers. As this epic is too large, let’s break it in to smaller user-stories:

  • As a user I would like to search my emails by keyword so that I don’t need to find them manually
  • As a user I would like to limit my search to one field as that’s important for me to begin with
  • As a user I would like to search my emails with attachments so that I don’t need to find them manually

INVEST Principle: Characteristics of Ideal small user-story

An ideal user-story should follow the INVEST principle

I – Independent

Stories are easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order.

N – Negotiable

It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details.

V – Valuable

We don’t care about value to just anybody; it needs to be valuable to the customer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers.

E – Estimable

We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation.

S – Small

Good stories tend to be small. Stories typically represent at the most a few people’s days’ worth of work. Above this size, it seems difficult to know what’s in the story’s scope. Smaller stories tend to get more accurate estimates.

T – Testable

If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing.

Conclusion

User-stories are very important and relevant while working in Agile methodology. As they are very concise, they encourage face-to-face communication and collaboration for further confirmation. They are also written from end user’s perspective and the focus is to build an end-to-end production ready functional slice which provides business value to the end-user. As there is a lot more focus on communication with just enough documentation which is useful for the team from maintenance standpoint.

Please share your thoughts and queries on the usage of user-stories in your projects in the comments section.

Got a question for us? Please mention them in the comments section and we will get back to you.

Related Posts:

PMI-ACP Training

How valuable is PMI-ACP to your Career?

Agile Methodology and Importance of PMI-ACP

PMI-ACP is a registered mark of Project Management Institute, Inc. Edureka is a Global PMI® REP: ID 4021 

About Author
ShriKant Vashishtha
Published on Aug 22,2017
ShriKant Vashishtha is an enterprise Agile Coach, IT strategist and trainer. He is passionate about Lean Startup, enterprise Agile transformation, quality aspect of software development and DevOps.

Share on

Browse Categories

Comments
0 Comments