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

Openness

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.


GET TO KNOW the good practises & techniques

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.

Leadership & Management

AWB - 09 - Scrum Framework