User Story Characteristics In agile Scrum Methodology

User story is a description of objective, which helps a person to achieve a feature. So that he able to utilize that feature when using software application.

User story is a part of Agile development process. Every process has some characteristics which makes it clear and concise. User story is a first process is Agile development process. A good user story can convey a good understanding to programmer about requirement.
User story is a description of the user valuable features , good user story should include the roles, functions and business value of three elements.

As a (Role)
I Want (What)
So That (Why, Benefit)

User stories are most popular agile technique. It helps to capture the product functionality. User stories make work easy. Definition of an effective user stories can be hard. These given tips will help you to create an effective user stories.

Microsoft Press defines Acceptance Criteria as:

“Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.”

Google defines Acceptance Criteria as:

“Pre-established standards or requirements a product or project must meet.”

User Story Characteristics

Here is a short, but informative list of user story characteristics.

• A good user story should be complete enough to provide a user with some value.
• The good user story should be user-centric, normally people write user story too much centric around components or system aspects.
• When writing a user story, focus on what the user is doing or getting out of the story.
• The goal is that, when the user story is done, the user story has some value for users.
• Group the user stories which offers a feature in same domain, or its good to grouping a certain feature or use case into a single or multiple Epics.
• A good user story is written in one to three lines.
• Some user stories have attached files to elaborate the user story more clearly.
• Good user story is well-defined, well-detailed and comprehensive.
• A good user story is helpful to capture a specific functionality.
• Involvement of development team in the user story is important.
• A good user story is simple and concise.
• Good user story should always be in active voice. Do not use ambiguous and confusing terms.
• Good user story only focus on important part and leave out the rest.
• Start with an epic, when writing a user story about new product and feature because it allow to capture the rough idea about product with less detail.
• User Stories are used to communicate information, so make them visible and accessible.
• Good user stories are complemented with other techniques like, story maps, sketches, mockups, storyboards and workflow diagrams etc.
• Try to avoid dependencies between stories, dependencies between stories will have priority and planning issues.
• The story should be negotiable. User story should be changed or removed without impact to everything else.
• The best valuable user story is that one, which is written by user or customer. Give value to each user story which writes by user of customer.
• Developers should be able to predict (at least rough guess). They predict about time scale of stories , and to achieve the desired encoding.
• The story of scale is depend on team size, capacity development group , as well as technical realization.
• Good user story is a story which is easily testable. We cannot develop, what we cannot test. A non-testable user story is : “software should be easy and pleasant to use”.

There are two helping methods for writing user stories:

• Invest (This technique is helpful for user story)
• Smart (SMART is for the tasks of a user story)

Bill Wake’s user story Characteristics:

To build a good user story , we focus on six characteristics. A good story should have characteristics. Bill Wake described six characteristics of a good user story. We entitle his formula as “Invest”.

Invest

• I) Independent
• N) Negotiable
• V) Valuable
• E) Estimable
• S) Small
• T) Testable

Independent

We must try to avoid the interdependence between the story. When the story prioritize, plan to do or when to use the story, the story of the interdependence between the estimated workload will cause more difficult. Usually we can reduce the dependence of two ways:

• Interdependent story combined into a large, separate stories
• With a different way to split the story

Negotiable

Story card is a brief description of the function, the details of the discussion will result in customers and development teams in. The story is a reminder of the role of card developers and customers to engage in dialogue on demand, it is not a skill specific needs. A user story is a cassette with too many details, effectively limiting and user communication.

Valuable

User Stories should clearly reflect the values ​​of the user or customers, the best approach is to allow customers to write the story. Once a client realize that this user story is not in contract and can be negotiated, they will be happy to write the story.

Estimatable:

Development team needs to estimate a user story in order to determine priorities, workload scheduling. But let developers is difficult to estimate story Problems from:

• Developer lack of domain knowledge
• Developers lack of technical knowledge

Story too . . . .

Small

A good story on the amount of work to be as small as possible , preferably not more than 10 people over the workload / day, at least make sure that in one iteration or Sprint that can be completed. User Stories larger scheme of arrangement at risk , effort estimation and other aspects will be.

Testable

The story must be testable . Successfully passed the test developers can prove that correctly implements the story. If a user is not able to test the story , then you will not know when it can be done . An example of a non- test user stories : The user must find the software very easy to use.

Related: Agile User Stories and Groomed Product Backlog

Smart:

SMART is not for user stories but for the tasks of a user story.

• S) Specific
• M) Measurable
• A) Achievable
• R) Relevant
• T) Time-Boxed

Specific

A task needs to be specific enough so that everyone can understand it. It helps to keep other tasks from overlapping, and also helps people to understand either the tasks add up to the full story or not.

Measurable

The key of measure is, “can we mark it as done?” Team needs to agree on what that means, but it should also include:

• “what it is intended to”
• “tests are included,”
• “the code has been refactored.”

Achievable

The task owner must be able to achieve task. In XP methodology, teams have a rule, in which anybody can ask for help whenever they need; this is certainly includes ensuring that task owners are up to the job.

Relevant

Every task must be relevant and story contributing. User stories are broken into tasks for the developers benefit, but customer should still be able to expect that each task can be justified and explained.

Time-Boxed

A task should be limited to a specific duration. This doesn’t need to be a formal estimate in hours or days, but there must be an expectation so people know, when they should seek help. If a task is harder than expectation, then the team needs to split the task, change players, or do something to help the task (and story) to get done.