Software Testing

USER STORY

In software development and product management, a user story is an informal, natural language description of one or more features of a software system. It is the exact copy of user needs. It should be simple and easy to understand document.

A good user story should be – INVEST:

  • Independent: Must be understandable and identifiable does not depend one another.
  • Negotiable: It captures important thinks, at the end of communication. Does not make as a contract.
  • Valuable: Provide values to stake holders
  • Estimable: It must be estimable so prioritization done properly and fit to sprint.
  • Small: it is small chunks. So it can complete 3-4 days.
  • Testable: It has to be testable

User Story Template

User stories only capture the essential elements of a requirement:

  • Who it is for?
  • What it expects from the system?
  • Why it is important (optional?)?

Here is a simple format of user story used by 70% of practitioners:

More Focus On..

Highest Value Delivery:

It offers valuable product to the customer. It provides the priority for customer immediate needs.

Brings User Closer:

In agile software development methodology the team always interacts with end users regularly. So they can discuss project details at the presence of end users.

Building Blocks of the Product:

Software product builds incrementally. So we can adjust rapidly into new direction. User story allows quick implementation and faster feedback.

User Story Examples:

  • As a [customer], I want [shopping cart feature] so that [I can easily purchase items online].

The Pros of using user stories:

  • unification of the vision and communication, language between a client and a team
  • prioritizing functions
  • maximization of usability
  • boosting the creativity level through cooperation
  • facilitating time estimation of particular iterations

Cons of using user stories:

  • complications in the description of purely systemic tasks, Eg: bugs, spikes
  • discrepancy in the approach to the functioning of a given story between a client and a developer team
  • lack of information concerning the method of development and design interface – differences between developers
  • focusing on business functionalities and missing the technical ones, Eg:. Server’s efficiency
  • losing control of the whole vision resulting from functionality fragmentation

Author: STEPS

Leave a Reply

Your email address will not be published. Required fields are marked *