Sunday, September 10, 2017

What are User Stories in Scrum ? | Supreme Agile

תוצאת תמונה עבור ‪user stories scrum‬‏
Once stakeholders realize that a new development is needed (Software, Features Etc.), the agile process begins with the product owner (PO) that will translate the customer requirements into clear definitions of what the new software will do and what services it provides to its users.

This process is not unique and relevant for both Traditional and Agile methodologies, but the main difference is the “Way” and “Process” used by the product owner to translate these requirements, in traditional methodologies such as “Waterfall” the product owner will create a large heavy SRS/SPEC with lengthy requirements and specifications. This process of creating large heavy docs is not suitable for Agile; due to the nature of this methodology, the Product owner should use a lightweight approach of translating the customer requirements into short and clear descriptions of the pieces that needed in order to satisfy and provide value to the client.

Therefore, if in traditional model the product owner will use a SRS/Spec to define the customer requirements, in agile the product owner will use work items captured in the form of “User Stories”. A user story is an alternative way to express a software requirement in a very readable and structured form (based on the client perspective), that will add value to the customer once it is accomplished by the team.

The basic and very “Theoretical” format of a user story is:

Title: <Short and informative name of the user story>
As a <User>
I want to <Description of the action>
So that <I will get this benefit>

In addition to this basic format, user stories should also include the following fields:

The creator of the user story can be any team member.
Definition of Done (DOD)
Checklist that determines the conditions that allow the team to mark a story as completed.
Acceptance Criteria
List of conditions that needed to accomplish prior to the team be able to start this story.
Story ID
The story ID should be unique to differentiate it from other user stories.
The PO in a way that will increase the value to the customer should prioritize each story.
Effort Estimation
The estimate time (Story Points/Hours) that the team will need in order to deliver the user story.
Determine the owner of the story.
Value/Business Value
The value of the story for the customer/organization.

User stories and Area of responsibilities

Product owner
Scrum Team
Who can Write stories?
The product owner Is the one that has the main responsibility to gather and manage user stories. However, the scrum team and other stakeholders also have the power to create stories of their own

Type of stories
Stories that based on Organization/Customer Requirements and specification

Mostly technical stories that are not add a direct value to the customer

Who is the Owner of the story?
The PO is the owner of the stories prior to the commitment of the scrum team
Take the ownership during the sprint commitments
Who should Maintain the backlog stories?
The product owner should be the one that is responsible to manage the product backlog, but in order for him to succeed, he must involve the scrum, team as well, this collaboration take part throughout the backlog “refinement” meetings.

Who should Prioritize the story?
The product owner should determine which stories will developed first in order to increase ROI and value for the organization/customer
The team cannot determine the priority, but they still have a decisive part when it comes to technical stories that should developed in order for them to be able to accomplish the functional stories.
Who Will Execute the story?
Not relevant
The team is responsible to make the implementation

No comments:

Post a Comment

My Presentations