Additional resources

This section provides some useful resources and concepts that can be used during Scrum activities.

Organizing product and sprint backlog

The Product backlog consists of a list of features, requirements, functions, enhancements, and fixes that represent the changes to be done in the next product release.

The Product Backlog items represent the characteristics of a description, estimation, value, and priority of the requirements. These Backlog items are known as “User Stories”. The User Stories are also referred to as the Use Cases. The Product Owner is the one who is responsible for the Backlog items to prioritize the requirements based on the market value and customers’ feedback and or expectations.

Epics and User Stories

In simple terms, Epic is a big chunk of work which can be divided into smaller user stories. An Epic can be spread across sprints and even across agile teams.

An Epic can be a high-level description of what the client wants, and accordingly, it has some value attached to it. Therefore, Epics are more likely to be found in early stages of User Story definitions, and they still need to be refined, they are not ready to be considered during sprint planning unless a break down into smaller user stories is performed.

Epics are also a good mechanism for classification and grouping of user stories, they are very useful providing a way to structure the backlog in a more intelligible way. Epics must be assigned business value priority to have proper relevance in the product backlog list amongst other user stories and epics.

Note

User stories are much more detailed than Epics, they must have a fixed-length in effort able to fit into sprint duration.

INVEST criteria for product backlog

The user stories in the product backlog should completely satisfy the INVEST criteria:

• (I)ndependent In the specification level, the user stories are independent; they offer different functionalities and the user stories should not be overlapped.

• **(N)egotiable User stories in the next sprint are always subject to negotiations and checks the product with a Product Owner.

• (V)aluable Each user story in the next iteration should deliver value or benefit to the customers or the Developers.

• (E)stimable Product Owner should always be able to estimate the size of a user story with its fixed length.

  A user story should not be too long as it will not fit in the next iteration that becomes a useless plan/prioritize.

• (S)ized Each user story should be small enough to complete and delivered in a single sprint. The letter ‘S’ can be taken to be (S)ized appropriately to meet the Sprint weeks.

• (T)estable Each user story should have clear information or specifications to develop all the possible test cases from the acceptance criteria.

User stories depicted

A User Story is a description of an objective a person should be able to achieve, or a feature that a person should be able to utilize, when using a software application.

Note

User stories must be expressed as follows using basic structure: As an [Role] I want [Objective] so that [Benefit].

Acceptance criteria

Every User Story must have its own acceptance criteria. Acceptance criteria is a set of statements, each with a clear pass/fail result, that specify both functional (e.g., minimal marketable functionality) and non-functional (e.g., minimal quality) requirements applicable at the current stage of project integration. These requirements represent “conditions of satisfaction”/

Important

There is no partial acceptance: either a criterion is met, or it is not.

Acceptance criteria must be expressed clearly, in simple language the customer would use, just like the user story, without ambiguity as to what the expected outcome is.

Acceptance criteria should state intent, but not a solution (e.g., “A manager can approve or disapprove an audit form” rather than “A manager can click an ‘Approve/Disapprove’ radio button to approve an audit form”). The criteria should be independent of the implementation: ideally the phrasing should be the same regardless of target platform.

How to demo

This attribute of the user story helps the team to understand what the story is about. There are several benefits of writing how to demo, such as:

• Everyone is forced to agree what the story is about and understand it (and resize if necessary).

• It forces the product owner/customer to agree on how the story will be demoed during the public demo.

• It ensures that the product owner/ customer has thought of the whole scope of the story and won’t bring up other pieces later in the sprint.

Priority

The priority attribute must be assigned only by product owner, he is in charge of aligning user story priorities with customer or business expectations. By mean of priority the product backlog is ordered in such a way that every time the most valued stories are pulled out first to be worked out in upcoming sprints.

The possible range of values for priority attribute must be defined by the team, no matter which scale is adopted, the important thing to note is that the higher value is assigned, the higher is the priority for the story to be considered in future increments or sprints.

Estimation

Estimation is a value to be provided by the team, based on the relative size (effort) needed to complete the story. The unit is local to the team, and is expressed in Points, or Scrum Points. The more prioritized is the user story, the most detailed and complete tends to be.

How to manage the sprint board

These are some guidelines on how to manage the sprint backlog properly.

Sprint barely started

At the beginning of the sprint the board should look like this:

Pay attention to the columns meaning. As soon as a task was pulled out to be started, it should be placed on checked-out column. Only when all tasks composing to the story are completed, the story is moved to “done” column, as is depicted below:

After first daily meeting

After first daily meeting, the sprint board should look like this:

Note

The burndown chart (at the right most side of the picture), acts as a velocity indicator, and is updated as each story becomes completed

After a few days

After a few days, sprint board should look like this:

Notice the unplanned items, it is important to keep track of items not being considered initially because they can affect sprint goal. They must be discussed during sprint retrospective, including ways to prevent it from happening again. This way, the team can improve estimation process and become more predictable in future sprints.

Sprint status insights provided by sprint board

Useful insights on sprint status just looking at the burndown chart:

• Overdue

• Priority not being followed

• Too many unplanned items