Monday, April 18, 2016

User Stories |Agile Practices

User Stories |Agile Practices

A user story is an alternative way to express a software requirement in a very readable and structured form (based on the client perspective), in addition, user stories are the main tool to create the communication between the clients that demand the requirement and the team that will do the implementation (Regardless the methodology you are using).

The basic format of a user story is:
As a <Role> I want <feature> so that <benefit>

Few more concepts that you should know about user stories
·         Stories are added to the project “backlog” and from there to the “Sprint Backlog".
·         User stories are written by the PO (Product owner) based on the client/Business requirements.
·         Each story provides an alternative vision for managing the requirements of the software.

User stories – The Responsibilities 

Product owner
Scrum team
Who can Write stories?

Write based on client/business requirements
Not Relevant
Who is the Owner of the story?

The PO is the owner of the story prior to the commitment of the scrum team
Take the ownership during the sprint commitments
Who should Maintain the story?

The PO when there is a change during the project
The scrum team during the implementation process
Who should Prioritize the story?

The PO will do it when he need to prioritize the most valuable stories (Most valuable stories are developed first).
Not relevant
Who Will Execute the story?

Not relevant
The team is responsible to make the implementation

Why do we prefer to use "User Stories" in the agile methodology instead of a large SRS/STD doc that are used in the traditional methodologies?

Writing user stories is a simple task, you can describe the exact requirements without adding multiple long descriptions (Describes the exact requirements to follow).

User stories are a great way to increase the communication among the team members, and between the team and the product owner.

The team will review each story during the sprint "Planning" meeting, this will increase the discussion between the team members (Especially when the need to make the requirements analysis) so they will increase the knowledge prior to implementation.  

All in one
Each user story contains all the relevant information that the team members need to start the implementation (Acceptance criteria, Requirement specification and Done criteria).

User stories will allow the team to evaluate each story so they can determine the work effort prior to taking any commitment during a sprint.

Remember that each user story contains the work effort that the team needs prior to complete it, this effort is reflected in Hours that are reflected in the sprint "Burn-Down" chart that allow the PO/SM/scrum team members to determine the amount of work that completed/remained during a specific sprint.

Team Velocity
User stories are evaluated with "story points" these allow the scrum master/PO to determine the team 'velocity' thought the process, this info will determine the team capabilities and how much stories they can handle during a sprint.

How can you test the quality of your stories…?

The team discuss about the stories
A good user story will increase the discussion between the team members and reduce the need in detailed documentation, in other words, the team members will focus on how to accomplish the story and not to waste their time on writing every small detail.

Reduce the waste of Time
When you have a well written story, the team can start the implementation without wasting a precious time, in any case that you have a partial story or a story that haven’t written well, the team will have a delay in starting the story (or difficulties during the implementation), Examples:

·      Stories that have a Missing information (Acceptance criteria, Requirement specification and Done criteria) that the team cannot continue until you add it.
·       Stories that the team asks too many questions due to misleading information. 
·       Stories with very high uncertainty.

Everyone can understand them
It's simple, a good story will be the one that both the team and the customer can understand and Explain when asked. If one of them cannot due one of the two, the story is just not good enough.

A major concept in the scrum methodology is the using of "Story Points" to evaluate the work effort of a story, if the story is too big, cannot be tested or any other cause that is affecting the ability of the team to vote, this story should be re-written (Split to smaller stories, change the criteria…). This issue has become more important when such stories are arriving during the planning meeting where the team should make the actual voting cycles (poker game).


Additional concept in agile, is to create incremental software releases that will add the best value for the client, a good story will be the one that the team can implement and get the best value for the client. 

No comments:

Post a Comment

My Presentations