Monday, September 18, 2017

Benefits of User Stories in Scrum | Supreme Agile

תוצאת תמונה עבור ‪stories in agile‬‏

Simplicity

User stories are simple and fast to write, both the customer and the team can describe the exact requirements (Functional and Non-Functional) without using, multiple long descriptions of the task that they want to achieve.

This simplicity will contribute to the process because the customer does not need to know the technical aspects of his requirements, the simplicity in writing user stories will help him to use a basic language to reflect his functional needs.

Written by the customer

User stories based on the customer requirements that knows what he wants to get at the end of each iteration. This allows the scrum team to communicate directly with the customer (or with the product owner that represent him) to get a better understanding of the real needs and what they should deliver.

Easy to Prioritize

Once the user stories added to the product backlog, the product owner with the team has the opportunity to understand which stories are more important to the customer. Following this basic approach, the PO and the team can prioritize the important user stories first; this prioritization will guarantee that the team will deliver the most important user stories first which will lead to happy customers.

Communication

User stories are a great way to increase the communication among the team members, and between the team and the product owner, a good user story will enable the relevant stakeholders to make a real conversation about the requirements and expectations of the customer.

Collaboration

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) without searching different parts of the data between multiple resources.

Commitment

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.

Tracking

Remember that each user story contains the work effort that the team needs prior to complete it, this effort 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.


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:


Artifact
Description
Creator
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.
Priority
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.
Owner
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

Tuesday, September 5, 2017

Definition of DONE (DoD) in Scrum | Supreme Agile

תוצאת תמונה עבור ‪definition of done agile‬‏





In order for a scrum team to be able to understand when a user story from the Sprint Backlog can be marked as "Done", the team will use a technique called "DoD" that is used to determine a set of Requirements, conditions and quality factors of necessary activities that must be completed to ensure that the team will deliver the user story in the highest quality to add value to the customer.

In addition, a good DoD, will help the team members to get a clear understanding of what is expected from them per story, which will reduce the uncertainty and will allow them to focus on the things that matter. Some great examples for that is that DoD is also used to determine if all tasks are written during sprint planning and also as a checklist at the end of the sprint to verify whether all activities were completed by the team 


DoD at various Scrum levels

We can use DoD on different project levels, the simplicity and clarification that a good DoD provides for the team can be added to many other scrum process and Artifacts, Examples:

  1. Definition of Done for Sprint (Collection of goals that the team must develop within the sprint time-frame).
  2. Definition of Done for product release (It’s the PO decision to decide on the criteria of what it takes to release the product).
  3. Definition of Done for a user story (Commitment to the product owner).
  4. Definition of Done for a Task (Tests are passed in 100%, Code is implemented, Code review was made Etc.).

What is a typical DoD will look like?

A DoD may look different between one scrum team or another, but the typical DoD would be similar to:

  1. An HLD will be written and reviewed by the team.
  2. The code will be implemented and code review is made.
  3. The new code should be covered with tests at all application levels (Unit, component, Integration, and System).
  4. The code should be integrated into version 1.0.
  5. A working service should be presented in the review meeting.

Expected Benefits of using DoD


  1. The Definition of Done will help the team to understand what is expected from them once they take commitment on a user story.
  2. The Definition of Done will help the team to make a better time estimation because they can understand the work effort they need to put in order to complete the DoD.
  3. The Definition of Done will help the team to gain a shared understanding to ensure transparency.

My Presentations