The software is built in response to inputs (or requirements) voiced by a wide variety of

stakeholders. (customers, end users, subject matter experts, developers, etc)

It is the job of a person, who plays the Product Owner role to collate all these inputs and turn it into
a “backlog” of requirements. (The backlog consists of all the things that the team could do for the
customer, ranked in priority order.) The backlog is obviously a live document or list that the product
owner continuously updates.

The release backlog is a sub-set of the product backlog and represents the items that the team has
agreed to implement within a given release of the product. -The Sprint backlog is a sub-set of the
release backlog and represents the items that the team has agreed to implement within a given
Sprint.
The product backlog may contain epics and stories.

A user story is an atomic requirement that the team works on in an Agile project. All the stories
contribute to the completion of the feature.

An “Epic” is a way of grouping stories together –either based on a higher level goal or by simply
aggregating or grouping a large number of stories together. An example of an epic could be
“Improve scalability”. Within this epic, you could bunch all the stories that are required to
accomplish the work of improving scalability. For example, it may include stories to tune the
database queries, support multi-threading, etc.

The Scrum Team comprises of the Product Owner, the Scrum Master and the developers. (The job of
the Product owner is to provide “direction” to the team. The Product owner needs to tell the team
what to do and what is the preferred order of priority in which it needs to be done. In short, for the
team, the Product Owner is the proxy or representative of the customer, who is also authorized to
take decisions on behalf of the customer.)

The Scrum master facilitates the interactions of the team by organizing the Scrum rituals and
conducting the meetings. A scrum master protects the team. The team needs to be protected from
interference or disturbance while they are busy doing the work needed for the project. He helps the
team understand the methodology, resolves implementation challenges and coaches the team
about the methodology. A scrum master would provide guidance to the team in terms of explaining
and sharing best practices, providing templates for commonly used tasks, etc.

The team aka Developers. The team should be “cross-functional”, i.e. they must have all the skills
necessary to complete the work needed. Also, the Scrum team needs to be self-managing, i.e. they
take responsibility for making decisions – making commitments and making efforts to live up to their
commitments.

Once you have the backlog, you are ready to start working in Sprints or Iterations.(A Sprint is a short
duration milestone (typically 1 to 4 weeks long) in which the team takes a sub-set of the product
backlog and tries to bring it to a near releasable state by the end of the Sprint.[The sub-set of the
product backlog that the team commits to complete within a sprint is called the Sprint backlog. ] )

At the end of the Sprint, there are two important Sprint rituals – the Review and the Retrospective.
The review is a meeting that takes stock of what the team has built during the Sprint in the form of a
working demo. The retrospective is a “lessons learnt” meeting where the team tries to draw lessons
from the past Sprint and use it for planning subsequent Sprints.
No changes in a Sprint

The shorter the overall release cycle, the shorter each Sprint should be. -The amount of uncertainty.
If there is too much uncertainty in the work involved, you would typically want longer Sprints
(Remember that once the items are prioritized for a given Sprint, the Sprint backlog cannot be
changed – in effect the customer has to wait until the beginning of the next Sprint for their amended
priorities to reflect in the plan. Once the team has committed to doing a certain amount of work at
the beginning of the Sprint, the Sprint backlog cannot then be changed, i.e. the work load or work
content cannot be changed -Substantial changes to be the committed stories are not allowed -Also,
the Sprint deadline cannot be changed. They can add the change to the product backlog ask the
customer to wait until the start of the next sprint to prioritize the request. )

Daily Scrum

The daily scrum is a short (no more than 15 minutes) meeting in which the entire team gets together
and each team member provides a very short description that answers the following questions. -
What I did yesterday (or since the last meeting) -What I plan to do today (or until the next meeting) -
What is in my way (or what is blocking my progress) Remember these are NOT status meetings or
the team members reporting into some higher authority. These are team members providing
information to each other and making commitments to each other.

Sprint Review

The mandatory attendees to this meeting are the team, the Scrum master and the product owner.
In this meeting, the team provides a demo of the working software that the team has built. It should
not be a power-point or document – just a quick, live demonstration that shows how the
requirements were implemented in reality. It is important to record all the feedback and use it to
fine-tune the product backlog. The Sprint review is important because it helps the team validate that
they are on the right track. Feedback helps them get closer to the customer’s expectations. It also
confirms whether the team is making enough progress as per the release plan or not.

Sprint Retrospective

The retrospective is a 1-2 hour meeting at the end of the Sprint (typically after the review) that helps
the team to review what is working and what is not. The mandatory attendees for this meeting are
the Scrum Master and the team. Sometimes you may invite the product owner too. It is important to
understand that the sprint retrospective is a meeting of the team, by the team and for the team. It is
not a performance review for senior management where the team’s performance is being assessed
by the senior management. Nor is it a post-mortem meeting where the goal is to assign blame. The
retrospectives are important because it gives the team visibility into the issues and helps them to
take control of actions needed to correct course and make their work environment more efficient
and more productive. [Some good practices in conducting effective retrospectives are as follows. -
Start by creating 3 lists: What is Working, What is not working well and What we could try (to
change or to introduce) in the next Sprint]