AWB - 09 - Scrum Framework

299 Agile White Book – AXA Emerging Markets EMEA-LATAM
Chapter 9
SCRUM FRAMEWORK
V1.0

Contents
WHAT WILL I LEARN FROM THE CHAPTER?................................................................................................................................................................ 302
SCRUM AT A GLANCE ........................................................................................................................................................................................ 303
WHAT DOES IT TRY TO SOLVE?...............................................................................................................................................305
GET TO KNOW THE CORE OF SCRUM ................................................................................................................................................................... 307
THE TEAM..........................................................................................................................................................................307
VALUES..............................................................................................................................................................................308
APPROACH & TOOLS............................................................................................................................................................310
ROLES ...............................................................................................................................................................................311
STEP-BY-STEP PROCESS.........................................................................................................................................................315
LEARN THE ARTEFACTS ...................................................................................................................................................................................... 319
PRODUCT BACKLOG.............................................................................................................................................................319
SPRINT BACKLOG.................................................................................................................................................................320
PRODUCT INCREMENT..........................................................................................................................................................320
UNDERSTAND THE PURPOSE OF THE MEETINGS ...................................................................................................................................................... 321
SPRINT PLANNING ...............................................................................................................................................................322
DAILY SCRUM .....................................................................................................................................................................323
SPRINT REVIEW...................................................................................................................................................................325
RETROSPECTIVE...................................................................................................................................................................326
PRODUCT BACKLOG REFINEMENT ..........................................................................................................................................327
GET TO KNOW THE GOOD PRACTISES & TECHNIQUES ............................................................................................................................................... 329
USING AN INITIAL PHASE.......................................................................................................................................................329
INCLUDING INDICATORS OF VISIBLE PROGRESS .........................................................................................................................329
BURN-DOWN AND UP CHARTS ...............................................................................................................................................330
DEFINITION OF DONE...........................................................................................................................................................332
DEFINITION OF READY..........................................................................................................................................................333
IMPEDIMENTS BACKLOG.......................................................................................................................................................334
IMPROVEMENTS BACKLOG....................................................................................................................................................335
TAKE AWAY.................................................................................................................................................................................................. 336

Scrum
Scrum is a lightweight Agile framework used
primarily for managing incremental product
development. Scrum begins when some
stakeholders need a product and ends with a piece
of working software. It implements a set of clear
principles, practises, mandatory meetings and
deliverables to allow teams to deliver more value
and get constant feedback.

What will I learn from the chapter?
SCRUM FRAMEWORK
I know Scrum and its benefits.
I know the Scrum roles and its practises.
I know the good practises & techniques.
SCRUM
BENEFITS
KNOW THE
SCRUM ESSENCE
- Values
- Roles
- Teams
- Mindset change
KNOW PRACTISES &
CONCEPTS
- Time-box
- Business Value
- Sustainable pace
- Short iterations
- User Stories
- Mandatory meetings
- Etc.
UNDERSTAND THE
GOOD PRACTISES
- Visual
Management
- Extreme Prog.
- Charts
- Special backlogs

SCRUM at a glance
Scrum is an Agile framework for incremental product development that focuses on what is truly
important for the client; it requires:
 One or more cross-functional, self-organizing teams of between 3 to 9 people.
 Well-defined roles, meetings, values and practices to get quick feedback and
reduce the time-to-market.
 People creating, inspecting and adapting their processes within the framework
 Quality time for introspection and improvement during the whole life of the
product.

As a part of the development Team, I
frequently use Scrum in conjunction with
Extreme Programming (XP) practises.
SCRUM at a glance
Scrum is the most popular of the Agile frameworks in the community that uses fixed-length
iterations (Sprints) which are typically from two weeks to four weeks long.
The team finally builds a potentially shippable product increment (properly tested) in every
iteration that is something that can be shown as finished to the clients in order to check against
their expectations. This must be of high enough quality to be given to final users but it does not
necessarily mean that it has to be made public.
The potential Product Increment must meet the Scrum Team's current Definition of Done, and
the Product Owner must accept each component of it.

We work together (Business & IT) to
get the best possible product while
respecting each other 
SCRUM at a glance
WHAT DOES IT TRY TO SOLVE?
During the last years, we have seen one or more of the following problems when trying to develop
a product:
 Business and IT working in different “worlds” and not following a shared goal.
 Releases taking too long to be built.
 Stabilisation stages taking too long.
 Changes hard to make and quality falling.
 People demotivated, having no trust in each other or paralysed when trying to analyse a
complex problem.
Scrum provides a platform for people to work together effectively and makes visible every
problem that appears in its way to empower the finding of some new and creative solutions.

SCRUM at a glance
The essence of Scrum
In order for Scrum to work, it needs some positive habits for people to follow, such as:
 Making clear goals and visibly communicate them to the Teams.
 Allowing people to organise themselves around the work.
 Helping them regularly deliver the most valuable features.
 Receiving feedback from clients/stakeholders on a regular basis.
 Reflecting on the way of working in order to improve the processes.
 Making the team’s progress visible to the entire organisation.
 Communicating honestly about progress and risks.

GET TO KNOW the core of Scrum
THE TEAM
Doing whatever necessary to deliver the desired product is always high priority. In order to do
so, we recommend the practices and tools in use to be improved all the time and constantly
work to take advantage of them.
I generally advise to look for 2 main objectives:
 Develop a product that meets customer expectations in a fixed (time-box) and small
period of time with the idea to get feedback.
 Find motivated people that perform joint approaches to create synergies between
Business and IT; increase productivity and creativity; and continually improve the way
they do things.

VALUES
Scrum reflects the spirit of the Agile manifesto, its support for individuals and interactions,
working software, customer collaboration and responding quickly to change.
Scrum values are used at Team level and promote inclusiveness of people to work together as a
single unit moving towards a common goal and a shared commitment, it focuses on rapid
cycles, time to reflect and improving what is done. Everything we do is based on Agile values
and principles.
Scrum also provides a clear set of additional values to be followed when developing a product and
help mitigating risks resulting from erratic behaviours on the system.
Scrum
values
Focus
Courage
Openne
ss
Commit
ment
Respect

It is now time for you to take a look at them and think how they can be implemented in the whole
team/people around you:
Focus - because you focus on only a few things at a time, you work well together
and produce excellent work. In this way, you always deliver valuable items sooner.
Courage - as you are not alone, you feel supported and have more resources at your
disposal. This gives you the courage to undertake greater challenges.
Openness - as you work together, you practice expressing how you're doing and
what's in your way. You learn that it is good to express concerns so that they can be
addressed.
Commitment - because you have great control over your own destiny, you become
more committed to success.
Respect - as you work together, sharing successes and failures, you come to respect
each other and to help each other become worthy of respect.
It is generally a good practise to encourage discussion –but never to impose it- to allow people to
know their benefits.

There are also mandatory meetings such
as the Sprint Review, Daily Scrum, and
Retrospectives; most of them are time-
boxed (fixed time) and with clear
objectives.
APPROACH & TOOLS
Scrum approach mandates that any adjustment that the development team makes to any aspect of
the project is based on experience and learning rather than theory. Scrum basics include:
 A Product Backlog: a full list of prioritised requirements that defines
a product
 Small cycles with functionality ready-to-use: usable product that meets the
clients’ business goals (working software/product).
 Visual Management: tools to create an environment where things are obvious from
the minute you walk into the area.
 Regular interaction between business and IT.
 Quality time for reflection.

ROLES
In Scrum there are just 3 roles:
The responsibilities of the Product Owner are:
 Unique representative of all stakeholders and users. Works on a shared
vision and represents all interested parts.
 Facilitates priorities agreement in the Business side based on Biz
strategy and ROI.
o Manages the Release Plan.
o Manages and prioritises the Product Backlog.
o Looks after the profitability of the project (ROI).
 Accepts the completed product at the end of each iteration.
 Collaborates with the Development team in requirement analysis and
detailing, gathering requirements and making sure they are ready.
Product Owner requires a minimum of 50% dedicarion to support the operational needs of a Scrum
Team. Rest of time should be devoted to work on Product Management, customer needs, competitors
analysis, etc.
Product Owner

A Scrum Master is the key person who helps achieve the benefits of Scrum. These
are some of their responsibilities:
 Develops a high performance, motivated and self-organized team,
helps Business and IT to collaborate and improves continuously. Coaches,
empowers and shepherds the team.
 Process responsible, transmits the Agile values and principles. Makes
sure that they are understood and followed, and ensures that agile practices
work.
 Facilitates meetings, helps the discussions to flow and creates synergies.
 Removes impediments that the team cannot solve by itself.
Dedication for this role may be nearly complete for a team of 9 people. Equivalently, for a team of 4-
5 people's, dedication may be up to 50%.
We generally recommend finding a Scrum Master with a good command of soft-skills and
interpersonal skills with some knowledge of Agile and Lean Software Development. Teamwork,
change management, leadership, coaching, motivation and emotional intelligence are also a plus
that through coaching, the Scrum Master can improve on.
Remember that she is a very proactive person that shares the team’s difficulties and experiences,
works on their resolution and advocates transparency in all the duties.
Scrum Master

Development Team
A Scrum Development Team is a group of people who do the work of developing a
product. Programmers, testers, designers, writers, and anyone else who has
a hands-on role in product development is a member of the development team.
They constitute a cross-functional and self-organized team.
The responsibilities of the Team are:
 Estimating size of Product Backlog Items and providing a solution.
 Converting requirements into “ready” functionalities.
 Tracking their progress.
 Presenting the results to the Product Owner
We generally advise creating objectives between Teams that are as
independent as possible, so the ones to be completed by one team during a
Sprint are autonomous, from others. In order to achieve this, we believe that is
important to:
- Promote development of full features or "end-to-end" regarding the
type of requirement.
- Limit "components" oriented teams (teams dedicated to creating
reusable components for other teams) as it can create dependencies,
synchronization problems and less shared responsibility.
- Involve the people who will be part of the Team during its creation so
they can make decisions about it.
- Make sure the Team is fully dedicated to one product as otherwise
productivity could drop substantially.
- Make sure Teams are stable (over 2-3 years), so that its members
engage and learn from each other and understand their needs.

We can also consider some extra roles in order to make it more functional to a large corporation
reality.
Extended Team
Experts that collaborate on a part-time basis and communicate directly with
the Development Team. They are permanent team members.
Project Manager
This is role is still needed due to the complex environment and that the
organization is on its way to agilization. His main responsibilities are:
 Coordinates relationships with third parties and other plans
(Communication, trainings, HW & SW provisioning, etc.).
 Removes impediments that are out of the scope of the SM (mainly
organizational).
 Financial, terms and scope control.
 Project reporting.
Stakeholder
He has a real interest or stake in the project and can be a direct manager of the
Team members, the people providing funding for the project, a group of users,
etc. This is what he does:
 Works with the Product Owner to bring ideas to the Product
Backlog.
 Attends Sprint Planning meetings as needed to provide feedback
and expertise and also provides direct feedback to the Team during
Sprint Reviews.
 Avoids distracting the Team during a Sprint — after the Team has
made a forecast for the Sprint.
Extended Team
Project Manager
Stakeholder

STEP-BY-STEP PROCESS
Let us show you in 5 steps an overview of the whole process. Although you may not initially be familiar
with all terminologies in here, you are going to find a detailed explanation of them later on. The idea
here is to give you a general overview of the processes in order for you to understand how each
piece fits into the whole framework.
A Vision is Created for the product and an initial Product Backlog is defined by
Business; this is basically a list of goals and high/medium level features feasible to be
developed. Many techniques are used during this stage to prioritise and decide what is
worth doing.
A Release Planning meeting is carried out in order to decide what is needed in each
Product Increment and Release and roughly decide what is going to be developed in
each Sprint.

Before the Sprint starts, the Product Owner selects a set of features that are related to
a specific Goal and presents them to the Team during a Sprint Planning meeting.
The Development Team examines the requirements, negotiates and agrees on the things to
be developed (it is not unusual to use Story points and Average Velocity to decide what to
take on-board (check chapter 4, Agile Requirements for more details); this list of functionalities is
called Sprint Backlog. As the Team agreed on them, they can start breaking them into smaller
tasks.

Sprints should have the same size in
order to generate a positive and
regular cadence.
The Sprint starts right after the Sprint Planning meeting with the Team members developing
the different tasks. The Sprint duration varies but it is generally 2 weeks to 1 month.
During the Sprint, there is a daily meeting called Daily Scrum, which is time-boxed to a
maximum of 15 minutes where the Team provides their tasks status and raises a flag in case
there is any impediment. Meanwhile, the Scrum Master is responsible for solving any roadblock
that may arise.

Many charts can be used to help the Team understand where they are; an example is the Sprint
Burndown.
When the Sprint is finished, the features are presented to the Product Owner as
working and tested software and he approves what was shown in order to be included in
the Product Increment if necessary. This last meeting (Sprint Review) gives a lot of feedback
to everyone and helps defining new priorities for the upcoming Product Backlog items.
Finally, a Retrospective meeting is held in order to improve the whole process, including
everyone involved and the Company.

LEARN the artefacts
Scrum has 3 “official” deliverables, called artefacts. These consist of the requirements for the
overall product, the requirements for each Sprint, and the working software itself.
PRODUCT BACKLOG
The product backlog is simply a list of work items that need to be done over time. It is a core
element in Scrum and contains a prioritised list of ideas for the product and it is the single
source from which all requirements flow. This means that all work the Development Team does
come from here.
Every idea, enhancement, bug fix, documentation requirement is a Product Backlog item and each
of them includes a description and an estimate. The Product Owner is responsible and accountable
for maintaining the Product Backlog. Requirements are emergent, meaning that you don’t and
cannot know up front every detail about what is needed in the product. Having that in mind, consider
the following:
- The Product Backlog is a living document and requires constant refinement; many new
items will be added over time; existing items split to smaller items or removed.
- Elements are not generally expressed by using technical jargon.
- A day-to-day task for the Product Owner is to negotiate with stakeholders and the Team in
order to get the best possible scenario for the product.
- Items need to be sized in order to determine the likely relationship between value, time and
cost.
- Items might change as their relative values could be seen differently today from yesterday.
We generally use User Stories to express the content of a Product or Sprint Backlog item; check
Chapter 4 (Agile requirements) for more details.

LEARN the artefacts
SPRINT BACKLOG
The Sprint Backlog is the list of refined Product Backlog items chosen by Product Owner and
accepted by the Development Team for the current Sprint, together with the team's plan for
accomplishing the work; it reflects the team's forecast of what work can be completed.
With the Sprint Backlog in place, the Sprint begins, and the Development Team develops the
new Product Increment defined by the Sprint Backlog.
If a previously agreed item can’t be finished during the Sprint, the Team would not get the
points from it, the implementation will be removed, taken back to the Product Backlog and a
negotiation with the Product Owner will start to potentially include the feature in a near future.
PRODUCT INCREMENT
The most important Scrum artefact is the Product Increment. Every Sprint produces one, it
means, something with high enough quality potentially, can be given to the clients. The
Product Increment must meet the Scrum Team's current Definition of Done, and each
component of it has been accepted by the Product Owner (check more about Definition of
Done in Chapter 4, Agile requirements).

Remember that Teams need many
sprints to understand the new
concepts, break down old habits and
start working together as a Team.
UNDERSTAND the purpose of the meetings
As we have seen, the Sprint is the heartbeat of the Scrum cycle. It starts with a Sprint Planning
and ends with a Sprint Review and Retrospective. Each day during the sprint, the team holds a
Daily Scrum meeting.
Have in mind that:
 The length of the Sprint is fixed and can’t be extended
 Every meeting in Scrum is strictly time-boxed. This means that it has a maximum
duration but does not mean that it needs to occupy this full time.
 We find two-week Sprints a good length to start with and after four to five of them, you
can let the team re-assess the sprint length.

UNDERSTAND the purpose of its meetings
SPRINT PLANNING
Sprint planning is divided in 2 parts but it is the same meeting. During the first part (What will
be done); the Product Owner presents to the Development Team a set of features he would
like and the team asks questions to understand the requirements in sufficient detail to enable them
forecast what can be achievable in the Sprint.
The team alone decides what it can deliver in the sprint, taking into account the sprint duration,
the size and current capabilities of its members, its Definition of Done, actions decided during
the Retrospective and anything else that could affect the Team performance. The Product
Owner must answer questions to clarify what she wants and the Scrum Master must ensure that
any other stakeholder needed to help the team is available.
Any new backlog item, for inclusion in the current Sprint and not previously estimated, needs to
be sized immediately during this meeting.
At the end of part 1, the team makes a forecast to the Product Owner what they believe they
can deliver in the form of running and tested features
In the 2nd
part (How will be accomplished), the team collaborates to create a high-level
design of the features it has forecasted to deliver. An outcome of this session is a more detailed
Backlog, or the list of tasks that the team collectively needs to execute in order to turn the items in
the selected Product Backlog into running tested features. This set of tasks is called the Sprint
backlog and is most often represented on a Kanban board.
During the second part, the team may have additional questions regarding the requirements and
any potential issue should be immediately communicated to the Product Owner.
Go to Chapter 6 “Sprint Planning” for more details.

1. What have I done since last daily scrum?
2. What I am going to accomplish by the
next daily scrum?
3. What impediments do I have?
Team members standing near the taskboard
while articulating the three questions
DAILY SCRUM
A Daily Scrum is a synchronization, inspection, and adaptive planning activity that a
development team performs each day. Since the team is collaborating, this is essential to ensure
continued progress and avoid work blockages. In this way the team continuously assesses its own
progress towards achieving its Sprint Goal and reorganizes the work as needed (the Sprint
Backlog).
This core practice in the Scrum framework is time-boxed to no more than 15 minutes. Attendees
find here brief clarifying questions and answers, but there is no discussion of any of these topics
during the Daily Scrum. However, many teams meet right after the Daily Scrum to work on
any issues that have come up.
Only the Development Team members speak during this meeting. Other interested parties can
come and listen in. The daily Scrum meeting is NOT for reporting progress to the Scrum Master,
Product Owner or Management. It is a communication meeting within the Development Team for
creating synergies. The aim of this meeting is directed solely at helping the team as a whole
deliver the next item in the backlog and that any impediments to doing this work are removed as
quickly as possible. The Scrum Master should also ensure the meeting is restricted to 15 minutes.

This is what I focus on:
 I moderate the meeting in order to keep it productive (to bring value to all attendees) and
not last more than 15 minutes.
 Detect who had an issue, is available/free to help/inform the rest about problems or
roadblocks.
 Identify what is ready.
 Know who to contact after the meeting in order to remove roadblocks.
You can also use a story-by-story approach considering the effort of the whole
team:
 What stories have been completed since last daily scrum?
 What features are we going to have completed by the next daily scrum?
 What features are currently blocked?

SPRINT REVIEW
At the end of each Sprint, the Development Team, Product Owner and Stakeholders review
the output of the Sprint in a time-boxed meeting called Sprint Review (around one hour per
week of Sprint duration).
The Sprint Review includes a demonstration of the new features the team has completed during
the sprint and its primary purpose is to inspect what the team has delivered, accept them
partially or totally, and gather feedback from the attendees to adapt the plan for the
succeeding sprint.
It is a good time to review Product Backlog Items and re-prioritise them based on the
feedback acquired.
Every interested part should be invited to the sprint review. Have in mind that Sprint reviews have
many possible outcomes including cancellation of the project.
The main point of discussion is the Product Increment completed during the Sprint. This is
generally an informal meeting to take a look at where you are and to collaborate on how
everyone might go forward. All people in here have input and can give an opinion.
Using the Product Increment, Product Owner checks the expected stories and each
acceptance criteria to make sure the features run as expected. If that is the case, the User
Story/Stories are accepted one by one.
During this meeting, everyone gives feedback and the Product Backlog is usually changed/updated.
The Sprint Review also gives everyone an overview of the current features.

RETROSPECTIVE
The retrospective is the final meeting of the Sprint. It follows immediately after the Sprint
Review and is unavoidable. Whereas the sprint review is focussed on the product, the
retrospective is focussed on improving the processes and Team. And whereas the Sprint
Review is open to the world, the sprint retrospective is restricted to the members of the
Scrum teams.
Go to Chapter 7 “Agile Retrospective” for more details.

PRODUCT BACKLOG REFINEMENT
Product Backlog Items are quite often large and quite general by nature, and since features and
ideas come and go and priorities change all the time, Product Backlog Refinement is an on-
going activity/meeting throughout a Scrum project and you should allocate around 10% of the
Sprint time for this.
These are the activities to do in order to maintain a proper Backlog and run a refinement session:
 Remove or lower items that no longer seem important.
 Add or promote items that arise or become more important.
 Split items into smaller items.
 Merge items into larger items.
 Estimate items.
 Check maturity of items.
The idea of a Product Backlog Refinement activity is to prepare for the upcoming Sprints. The
refinement activity gives special attention to preparing items that are coming closer to
implementation. There are many things to consider, including but not limited to:
 Each item entering the Sprint should ideally represent an increment of "business
value".
 The Development Team needs to be able to build each item within a single Sprint.
 Everyone needs to be clear on what is intended.
Go to Chapter 6 “Release planning” for more details.

The Product Backlog Refinement is best considered as an activity for all the team members,
even though the Product Owner runs it.
For simplicity, this activity can be split in 2 parts, the first one focuses on adding new items,
analysing or splitting Epics and adding new Acceptance criteria to them. The second part of
the meeting focuses on taking the “closer to development” items and going down into a little
bit more detail. This last part makes sure that the User Stories closer to be implemented meet
the Definition of Ready. Check chapter 6 (Agile Planning) for a detailed explanation of a Sprint
Planning meeting.
Read more about Product Backlog Refinement and Acceptance Criteria in chapter 4.

GET TO KNOW the good practises & techniques
There are some practises we use when implementing Scrum even if they are not the part of the
framework. They are optional but we have seen they add value to the framework.
USING AN INITIAL PHASE
We recommend starting a project with a Phase 0 (very short phase prior to the start of the first
iteration of development) where the project vision and an initial Product Backlog are created.
During this phase, the Product Owner prioritizes the list balancing objectives that give relative
value with cost and risk. Then a Sprint 0 is carried out to leave things ready for the project
(infrastructure, Product Maps, etc.).
Don’t forget that on a regular basis, the Product Owner maximizes utility to be developed and
the ROI of the project by re-planning goals/requirements during a meeting called Product
Backlog Refinement.
INCLUDING INDICATORS OF VISIBLE PROGRESS
Scrum always requires transparency inside and outside the Team. While the Product
Increment (working software) and communications are the most important ways of creating
transparency, Scrum Teams generally produce other deliverables to make sure that the status
of the project is understood. Common additional deliverables or artefacts, as they are called in
Scrum, can include Burn (up-down) charts, task boards, Kanban boards, etc.

BURN-DOWN AND UP CHARTS
A typical indicator of visible progress is a Burn-down chart. Here the amount of work completed
against the amount of work remaining is shown. One of the best reasons to use Burn-down charts
is that you can easily predict when you will potentially finish the requirements based on your
burn rate. This chart can be created at Sprint or Release level.

Burn-up chart can also be used and its mechanics is similar. The only difference is that instead of
showing how much work is left to be done, they track how much work has been completed, so the
curve is going up and not down.
The advantage here is visible when the product scope changes, as the line makes it clear that
something was added or removed.

DEFINITION OF DONE
While working software is being built, it needs to be "done" according to a shared
understanding of what "done" means. This definition is different for every Team, and as people
and teams mature, the Definition of Done expands and becomes more comprehensive.
The Definition of Done must always include the notion that the Product is of high enough quality
to be shippable.
Check Chapter 6 for more details (Agile Planning).
I would propose as samples the Definition of Done created by our team:
 Development
- Developed requirements
- Unit testing are successful
 Testing
- Classes in the repository
- Build and Deploy (integration environment)
- Integrated testing are successful at integration environment
 UAT
- The code is deployed at testing environment
- User Accepting test passed successful
 Deployment
- Prepare the deploy at production environment
- Deploy at production environment
- Execute testing (optional)

DEFINITION OF READY
By analogy with the "Definition of Done", the team makes explicit and visible the criteria that a
requirement must meet prior to being accepted into the upcoming Sprint. In this way, the Team
can make sure that requirements are mature enough to be developed.
The Definition of Ready created by our team:
 Team accepts as well defined:
o PBI.
o Acceptance Criteria.
o User Experience (UX).
 Team considers that it’s possible complete the PBI in the next Sprint.
 All dependencies have been identified
 All the risks were considered
 The team has identified any external specialist whose collaboration is necessary to develop
the selected PBIs.
 Team has a good approach how to show the completed PBIs in the next Sprint Review.
 Team has identified people who will do the review and acceptance of the PBI.
I can also bring to your consideration the Definition of Sprint Backlog Readiness in use by our
team:
 Sprint Backlog is prioritized.
 Sprint Backlog included all the PBIs following:
o There isn’t hidden work.
o There isn’t pending work at the beginning of the sprint.
 All team members have calculated their capacity Sprint.
 All selected PBIs accomplish the follow Definition of Ready:

IMPEDIMENTS BACKLOG
As you can imagine, there are always challenges that have the potential to impede the Team from
delivering successfully. We recommend you to record and prioritise them on an Impediments
Backlog and then find the way to work and remove the highest priority as quickly as possible.
Remember that the Scrum Master should resolve anything that impedes the Team from achieving
the Sprint Goal as soon as possible.
Impediments are generally gathered during the Daily Scrum and prioritised after the meeting.
You can also reserve a place on the Kanban board to group items and make them visible.

IMPROVEMENTS BACKLOG
It is useful to place a list of prioritized actions that the team came up with during a
Retrospective in a Kanban board or any other handy place. Teams generally choose two to four
improvement actions and work to resolve them, but sometimes, as the Sprint moves along, they
forget part of them.
Just like requirements, improvements items need to have an Acceptance Criteria; it means, a
clear definition of what is needed to consider them solved.

TAKE AWAY
REMEMBER
 Scum values need to be followed.
 None of the main roles and responsibilities are optional.
 Everyone should understand what Scrum is, its artefacts and how a time-box works.
 A clear and feasible strategy needs to be drawn before implementing Scrum.
DEEPEN YOUR KNOWLEDGE
 Scrum Alliance
 Scrum Organisation
BENEFITS
 IT and Business work together following a common vision and goal.
 Scrum reduces the time to market and keeps people engaged and motivated.
 Focuses on what a client really needs.
 Allows stakeholders to review what is produced in small iterations.
 Gives quality time to teams to reflect about their practises.

AWB - 09 - Scrum Framework

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (13)

Similar to AWB - 09 - Scrum Framework

Similar to AWB - 09 - Scrum Framework (20)

Recently uploaded

Recently uploaded (17)

AWB - 09 - Scrum Framework