Agile - Primer

Roles in Agile

Scrum Master

A Scrum Master is a team leader and facilitator who helps the team members to follow agile practices so that they can meet their commitments. The responsibilities of a scrum master are as follows −

To enable close co-operation between all roles and functions.
To remove any blocks.
To shield the team from any disturbances.
To work with the organization to track the progress and processes of the company.
To ensure that Agile Inspect & Adapt processes are leveraged properly which includes
- Daily stand-ups,
- Planned meetings,
- Demo,
- Review,
- Retrospective Meetings, and
- To facilitate team meetings and decision-making process.

Product Owner

A Product Owner is the one who drives the product from business perspective. The responsibilities or a Product Owner are as follows −

To define the requirements and prioritize their values.
To determine the release date and contents.
To take an active role in iteration planning and release planning meetings.
To ensure that team is working on the most valued requirement.
To represent the voice of the customer.
To accept the user stories that meet the definition of done and defined acceptance criteria.

Cross-functional Team

Every agile team should be a self-sufficient team with 5 to 9 team members and an average experience ranging from of 6 to 10 years. Typically, an agile team comprises of 3 to 4 developers, 1 tester, 1 technical lead, 1 product owner and 1 scrum master.

Product Owner and Scrum master are considered to be a part of Team Interface, whereas other members are part of Technical Interface.

How an Agile Team Plans its Work?

An Agile team works in iterations to deliver user stories where each iteration is of 10 to 15 days. Each user story is planned based on its backlog prioritization and size. The team uses its capacity − how many hours are available with team to work on tasks − to decide how much scope they have to plan.

Point

A Point defines how much a team can commit. A point usually refers to 8 hours. Each story is estimated in points.

Capacity

Capacity defines how much an individual can commit. Capacity is estimated in hours.

What is a User Story?

A user story is a requirement which defines what is required by the user as functionality. A user story can be in two forms −

As a <User Role> I want <Functionality> so that <Business Value>
In order to <Business value> as a <User Role> I want <Functionality>

During release planning, a rough estimate is given to a user story using relative scale as points. During iteration planning, the story is broken down into tasks.

Relationship of User Stories and Tasks

User story talks about what is to be done. It defines what a user needs.
Task talks about how it is to be done. It defines how a functionality is to be implemented.
Stories are implemented by tasks. Each story is a collection of tasks.
User story is divided into tasks when it is planned in current iteration.
Tasks are estimated in hours, typically from 2 to 12 hours.
Stories are validated using acceptance tests.

When a Story is Done

The team decides what done means. The criteria may be −

All tasks (development, testing) are completed.
All acceptance tests are running and are passed.
No defect is open.
Product owner has accepted the story.
Deliverable to the end-user.

What is Acceptance Criteria?

Criteria defines the functionality, behavior, and performance required by a feature so that it can be accepted by the product owner. It defines what is to be done so that the developer knows when a user story is complete.

How the Requirements are Defined?

Requirements are defined as

A User Story,
With Acceptance Criteria, and
Tasks to implement the story.

Previous Page Print Page