What is a User Story?

A user story is an informal, general explanation of a software feature written from the perspective of the end user. A user story is the smallest unit of work in an agile framework. expressed from the software user’s perspective.

The three aspects of user stories are,

  1. Card

Where are user stories written? On cards. They are written manually on index cards and this exercise helps keep the user stories concise. The card will have only enough information to identify the requirement and help everyone understand what the story is.

The card represents the requirement and is a great tool for planning. The Product Owner, after finalizing the user story to be picked up for the particular sprint, will hand over the user story card to the developers.

  1. Conversation

The card is the first step toward formulating the user story, but the requirement needs to be further discussed and refined, and communicated to the developers. This is done through conversation. The conversation between developers, Product Owners, Scrum Master, and the stakeholders also fosters collaboration between all, thus helping in getting a shared understanding of the requirement and leading to the development of the product.The conversations are mostly verbal, documents can be used for support.

  1. Confirmation

Even with the most in-depth conversation, there is always an element of doubt about the requirement that has to be created. How do we proceed with the user story and ensure that this is what the requirement states? This is done through the third C of the user story— ‘confirmation’. Confirmation is in the form of acceptance tests. The confirmation is the acceptance criteria that captures the essential requirements and helps us test the created product to ensure that it meets the defined criteria. Acceptance criteria are generally created by the Product Owner and further refined and extended in the backlog refinement. The developers implement the acceptance criteria or acceptance tests. The increment created based on the user story should satisfy the acceptance tests, which confirms that the feature has been implemented correctly. The developers, at the end of the iteration, demonstrate the completion of the story by passing the acceptance criteria. This is confirmation completed.

When these three Cs of the user stories are completed and satisfied, the feature created is complete and can be released.

Importance of User Stories

  • A key component of agile software development is putting people first, and a user story puts end-users at the center of the conversation.
  • These stories use non-technical language to provide context for the development team and their efforts.
  • After reading a user story, the team knows why they are building, what they’re building, and what value it creates.
  • They help provide a user-focused framework.

To whom user stories are assigned?

User stories are a few sentences in simple language that outline the desired outcome. They don’t go into detail. Usually, user stories are assigned to customers, end-users or even team members.

If you are using the User Story items merely as a container for Task items, without any defined states or transitions, then it is quite logical to leave the User Stories unassigned.

But, if you transition the User Story items from ‘Open’ to ‘In Progress’ to ‘Done’ along with the Tasks they contain, then you should assign the User Story to the person responsible for keeping the User Story state consistent.

Many times, team members create user stories but do not assign them to other team members or end-users.

There is no hard and fast rule about assigning User Stories within many of the tools available. In fact, some tools may not even support it.

Importance of assigning user stories

  • Addressing the expected user value of the product.
  • User stories allow developers to gain a keen sense of the specific requirements to be followed by the team.
  • The main purpose of user stories is to simplify the essential core of the project and the fundamental requirements needed to make it usable.

Kaiburr keeps continuous track of the stories without assignees, in each and every sprint through the powerful and unified Measurement and Benchmarking dashboard of its standardized  DevSecOps interface.

Stories without Epic and Initiative

Epics and Initiatives

Epics are made up of stories, initiatives are made up of epics. Initiatives offer another level of organization above epics. In many cases, an initiative compiles epics from multiple teams to achieve a much broader, bigger goal than any of the epics themselves. While an epic is something you might complete in a month or a quarter, initiatives are often completed in multiple quarters to a year.

‘User stories are an inevitable part of an epic.’

A user story can stand on its own. There is no mandatory approach that requires an epic first and then deconstruction into specific levels. The basic rule of thumb is user stories should be detailed enough for the team to start development with minimal discussion and a clear expectation of the outcome.

Importance of Epics and Initiatives

Epics came into the picture to differentiate between user stories that were high level and those that were smaller, able to fit into a sprint, and contained specific acceptance criteria.

It is a good practice to have an “Epic” defined before any user stories can be created.  Epics become an organizational technique to manage a story map or backlog, so user stories are grouped logically. This seems to imply that an epic is required for every user story. Epics are part of an initiative, so, apparently, user stories are required to have epic as well as initiative.

Kaiburr finds and keeps continuous track of the stories without epic and    initiative, through the powerful dashboard of its standardized  DevSecOps interface.

Kaiburr enables Engineering Excellence

With just 15 minutes of configuration, Kaiburr produces real-time actionable insights on end-to-end software delivery with its best practices and AI/ML models. Besides helping in end-to-end software delivery, Kaiburr supports Agile product development practices, Code quality, Security, Deployment, CI-CD, Branching, ALM and Testing too. Kaiburr integrates with all the tools used by the enterprise Agile teams to collect the metadata and generates digital insights with a sophisticated next generation business rules engine.

Reach us at contact@kaiburr.com to get started with metrics driven continuous improvement in your organization.