Scrum - An Agile Approach To Manage Successful Projects English PDF

An Agile Approach To Manage Successful Projects
2019
www.certmind.org
1 - Scrum – An Agile Approach to Manage Successful projects
Scrum – An Agile Approach to Manage Successful projects

This book was developed By CertMind As a guide for the successful management of agile projects using
Scrum. The content described here is the result of several years of research carried out by our experts,
students and volunteers who contributed their valuable knowledge and made possible the construction of
this guide.
Even though there are several Scrum-based reference frames today, our focus is on article “TNew New
Product Development Game" Written in The Harvard Business Review By Hirotaka Takeuchi and Ikujiro
Nonaka and later the guide developed by Jeff Sutherland and Ken Schwaber.
This book is the fundamental basis for obtaining CM-SFC Certifications (Scrum Fundamentals Certified) –
CM-SMC (Scrum Master Certified) – CM-SDC (Scrum Developer Certified) -CM-SPOC (Scrum Product Owner
certified) and CM Scrum Expert.
Content
Scrum – An Agile Approach to Manage Successful projects ..............................................................................................1
1. Introduction to Scrum ...............................................................................................................................................................9
1.1-History ..........................................................................................................................................................................................9
1.2-Definition of Scrum .............................................................................................................................................................. 10
1.3-Anglicisms ................................................................................................................................................................................ 10
1.4-Structure of the guide ......................................................................................................................................................... 11
1.5-Scrum Uses .............................................................................................................................................................................. 11
1.5.1-When to use agile methodologies?....................................................................................................................... 12
1.6-Guide Clarifications .............................................................................................................................................................. 12
1.7-Scrum Scalability ................................................................................................................................................................... 12
1.8-is Scrum implemented or adopted? .............................................................................................................................. 13

2. The Scrum Team ....................................................................................................................................................................... 13
2.1-The Product Owner .............................................................................................................................................................. 14
2.2 -The development team............................................................................................................................................... 15
2.2.1-size of the development team ................................................................................................................................. 16
2.3 Scrum Master (Scrum master) .......................................................................................................................................... 16
2.3.1-The Scrum Master service to the product owner ............................................................................................. 17
2.3.2-The Scrum Master service to the development team .................................................................................... 17
2.3.3-The Scrum Master service to the organization ................................................................................................. 18
2.4-The values of the equipment ........................................................................................................................................... 18
2.4.1 – Commitment ................................................................................................................................................................ 18
2.4.2 – Respect........................................................................................................................................................................... 18
2.4.3-Proactivity ........................................................................................................................................................................ 18
2.4.4 – Receptivity-Opening ................................................................................................................................................. 18
2.4.5 – Focus ............................................................................................................................................................................... 19
3. Events in Scrum ......................................................................................................................................................................... 19
3.1-the Sprint (sprint) .................................................................................................................................................................. 19
3.1.1-Considerations on the duration of the Sprint ................................................................................................... 20
3.1.2-Sprint Cancellation ....................................................................................................................................................... 20
3.2 – Planning Meeting of the Sprint ............................................................................................................................. 21
3.2.1-Event data ........................................................................................................................................................................ 21

3.3-Daily Scrum (daily scrum) .................................................................................................................................................. 22
3.3.1-Event data ........................................................................................................................................................................ 22
3.4 – Sprint Review Meeting ..................................................................................................................................................... 23
3.4.1 Event data ......................................................................................................................................................................... 23
3.5 – Sprint Retrospective meeting ....................................................................................................................................... 24
3.5.1-Event data ........................................................................................................................................................................ 24
4. The Artifacts in Scrum ............................................................................................................................................................ 25
4.1-Product Backlog .................................................................................................................................................................... 25
4.2-Sprint Backlog ........................................................................................................................................................................ 26
4.2.1-Increment ......................................................................................................................................................................... 26
4.3-Information emitters ............................................................................................................................................................ 27
4.3.1-Scrum Board ................................................................................................................................................................... 27
4.3.2-Burndown Sprint Chart ............................................................................................................................................... 28
4.3.3 – Cumulative Flow chart ............................................................................................................................................. 29
4.4 – Registration of obstacles/impediments .................................................................................................................... 30
5. Principles of Scrum .................................................................................................................................................................. 30
5.1 -Empirical Control of processes (1) .......................................................................................................................... 30
5.1.1-Transparency .................................................................................................................................................................. 31
5.1.2-Inspection ........................................................................................................................................................................ 31
5.1.3-Adaptation ....................................................................................................................................................................... 32
5.2 – Self-Organization (2) .................................................................................................................................................. 32
5.2.1-Team Collaboration ..................................................................................................................................................... 33
5.2.2-collaboration with the client ..................................................................................................................................... 34
5.2.3-Multifunctional equipment ....................................................................................................................................... 34
5.2.4-Collective ownership of the product ..................................................................................................................... 35
5.2.5 – Team Motivation ........................................................................................................................................................ 35
5.3 – Simplicity (3) .................................................................................................................................................................. 37
5.3.1-Simple design ................................................................................................................................................................. 37
5.3.2-use of software tools ................................................................................................................................................... 37
5.3.3-Is it worth working with processes? ...................................................................................................................... 38
5.4 -Focus on customer value (4) ..................................................................................................................................... 39
5.5 – Compliance (5) ............................................................................................................................................................. 39
5.5.1-Blocks of time ................................................................................................................................................................. 39
5.5.2-Team Rules ...................................................................................................................................................................... 40
5.6 -Iterative development (6) ........................................................................................................................................... 40
6. Considerations for Project Management ............................................................................................................................ 41
6.1 -Hiring ................................................................................................................................................................................. 41
6.1.1-Roles of the project ...................................................................................................................................................... 41
6.1.2 -Hiring the team (staff) ........................................................................................................................................ 42
6.1.3 -Types of contracts ............................................................................................................................................... 44

6.1.4 -Project Finances .................................................................................................................................................... 45
6.1.5 -Hiring of suppliers ............................................................................................................................................... 47
6.1.6 – the "freelancers" ......................................................................................................................................................... 47
6.2 -Monitoring and control of the project ................................................................................................................. 48
6.2.1 -Office of Agile Project Management (APMO) .......................................................................................... 48
6.2.2-Project reports and reports ....................................................................................................................................... 49
6.2.3 -Quality tracking .................................................................................................................................................... 51
6.3 -Risk Management ......................................................................................................................................................... 52
6.3.1-Examples of common risks: ...................................................................................................................................... 52
6.3.2-Appetite for risk ............................................................................................................................................................. 54
6.3.3-Risk tolerance ................................................................................................................................................................. 54
6.3.4-life cycle of risk management .................................................................................................................................. 55
6.4 -Change Management .................................................................................................................................................. 58
6.5 -Product Design............................................................................................................................................................... 60
6.5.1 -Minimum viable product .................................................................................................................................. 61
6.5.2 -Product Feasibility Analysis .............................................................................................................................. 61
7. The life cycle in agile projects .................................................................................................................................................. 62
7.1 -Stage 1: Start of the project .......................................................................................................................................... 63
7.1.1 -Define the vision of the project (1) .................................................................................................................... 64
7.1.1.1 -Project Restrictions.............................................................................................................................................. 64

7.1.1.2 -Identify stakeholders .......................................................................................................................................... 65
7.1.1.3 -Definition of terminated (DoD) ...................................................................................................................... 65
7.1.2 -Form the Scrum team (2) ...................................................................................................................................... 67
7.1.2.1 -Collaboration Plan ............................................................................................................................................... 67
7.1.2.2 -Project start meeting or Kickoff ..................................................................................................................... 67
7.1.2.3 -Team Development model – Dr. Bruce Tuckman ................................................................................... 68
7.1.2.4 -High Performance equipment ........................................................................................................................ 71
7.1.3 -Build the Backlog Product (3) .............................................................................................................................. 71
7.1.3.1 -Classifying Product Backlog............................................................................................................................. 72
7.1.4 -Prioritize Backlog (4) ............................................................................................................................................... 72
7.1.4.1 – Urgency Prioritization ....................................................................................................................................... 73
7.1.4.2 -Visual Story Mapping ......................................................................................................................................... 73
7.1.5 -Define the delivery schedule (5) ......................................................................................................................... 74
7.1.5.1-Team Calendar ........................................................................................................................................................... 75
7.1.6 -Define the product architecture (6) ................................................................................................................... 75
7.1.6.1-Sprint Zero ................................................................................................................................................................... 76
7.1.6.2-Supplier evaluation and selection....................................................................................................................... 77
7.2 -Stage 2: Planning ............................................................................................................................................................... 77
7.2.1-Write User stories and tasks (7) ................................................................................................................................... 78
7.2.1.1-What are user stories? ............................................................................................................................................. 78

7.2.1.2-Mockups and initial project prototypes ........................................................................................................... 78
7.2.1.3-Parallel planning ........................................................................................................................................................ 79
7.2.1.4-Drill down user stories into tasks ........................................................................................................................ 79
7.2.2 -Prioritize User Stories (8) ....................................................................................................................................... 80
7.2.3 -Sprint Planning Meeting (9) ................................................................................................................................. 80
7.2.3.1-Select the work to be developed ........................................................................................................................ 80
7.2.3.2-Estimation of the selected work .......................................................................................................................... 81
7.2.3.3-Team Commitment ................................................................................................................................................... 82
7.2.3.4-How will you get "Finish" the selected work? ................................................................................................ 82
7.3 -Stage 3: Sprint Development ........................................................................................................................................ 84
7.3.1-Develop deliverables (10) ............................................................................................................................................... 84
7.3.1.1 – The development cycle for software projects ............................................................................................. 85
7.3.2 -Daily Scrum (11) ........................................................................................................................................................ 88
7.3.2.1-Sprint Progress tracking ......................................................................................................................................... 88
7.4 -Stage 4: Sprint review ...................................................................................................................................................... 89
7.4.1-Sprint Review Meeting (12) ........................................................................................................................................... 89
7.4.1.1-Technical debt ............................................................................................................................................................ 90
7.4.1.2-Refinement of the Product Backlog ................................................................................................................... 90
7.4.2 -Sprint Retrospective Meeting (13) ..................................................................................................................... 91
7.5 -Stage 5: implementation................................................................................................................................................. 92

7.5.1-Implementation Planning (14) ...................................................................................................................................... 92
7.5.1.1-Coordination with operations .............................................................................................................................. 93
7.5.2 -Implementation of deliverables (15) ................................................................................................................. 93
7.5.2.1 -Successful Implementation Confirmation .................................................................................................. 94
7.5.2.2-unsuccessful deployments ..................................................................................................................................... 94
7.6 -Stage 6: Closing of the project ..................................................................................................................................... 94
7.6.1 -Project closing (16) .................................................................................................................................................. 94
7.6.2 -Retrospective project meeting (17) ................................................................................................................... 96
8 Scrum in big projects .............................................................................................................................................................. 96
8.1 -Equipment Distribution .............................................................................................................................................. 96
8.1.1 – Program Owner .................................................................................................................................................. 97
8.2-Product Backlog in multiple equipment ...................................................................................................................... 97
8.3-Scrum Scrum ........................................................................................................................................................................... 97
8.4-Coordination of sprints ....................................................................................................................................................... 98
8.5 – Guidelines on Scrum practices ..................................................................................................................................... 99
9 Thanks .........................................................................................................................................................................................100
10 Official terms in English ..................................................................................................................................................100
10. List of figures .......................................................................................................................................................................101
11. Changes to the 2017 edition. .......................................................................................................................................103

1. Introduction to Scrum
1.1 - History
The history of Scrum can be traced from 1986 in an article from the Harvard Business review, "TNew New
Product Development Game" Written Por HirOtaka Takeuchi and Ikujiro Nonaka, in which they analyzed
the approach used by companies such as Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3m, Xerox, y
Hewlett-Packard For the development of Their Products.
During their research, they realized that these companies shared Six features: Built-in instability, self-
organized project teams, FASis overlapping development, multi-learning, subtle control and organisational
transfer of learning. The six pieces fit like a puzzle, forming a fast and flexible process for the development
of new products. Equally important, This New approach can act as an agent of change: It is a vehicle to
introduce creative and market-driven ideas and processes in an old and rigid organization.
It is also in this artíAss where you do the process comparison of Scrum With the Rugby game, And from
whence originates its name Scrum.
The original article can be read at: Https://hbr.org/1986/01/the-new-new-product-development-game
Subsequently are Ken Schwaber and Jeff Sutherland Who They worked in Scrum since 1995, when together
What They presented at the UNRWA conference in 1995. This presentation documented mainly the learning
that Ken and Jeff had obtained over the years and made Pública The first formal definition of Scrum. To
honor the first places where it was tested and perfected, we recognize Individual, Inc., Newspage, Fidelity
Investments and IDX (currently GE Medical).
Scrum's Guide documents scrum as it has been developed, evolved, and maintained for over twenty years
by Jeff Sutherland and Ken Schwaber. Other sources provide patterns, processes and ideas that complement
the Scrum framework. These can increase The Productivity, value, creativity and satisfaction with the results.
1.2 - Definition of Scrum
Scrum Es a framework through which people can address complex adaptive problems, while delivering
products in an efficient and creative way with the maximum value.
Scrum is:
• Light
• Simple to understand
• Difficult To dominate
Scrum is a framework composed of Practices That has beenn Used to Manage the Development of complex
products Since the beginning of the years 90.
Scrum is not a process, a technique, or a definitive method. On the contrary, it is a framework where you
can use a set of different processes and techniques. Scrum shows the relative efficiency of product and work
management techniques so that we can continually improve the product, equipment and work
environment.
1.3 - Anglicisms
In this book we use several terms originally used in English, this in order not to cause confusion with the
various translations that can be given to them. To Then You find the list of terms that were not translated
in this material:
• Burndown Chart: CFire Uadro or advance

• Framework Framework of work
• Product Backlog: Product Earrings List
• Product Owner: Owner of the product
• Scrum Board: Scrum Board
• Scrum Master: Scrum Master
• Sprint: Iteration
• Sprint Backlog: List of earrings of the Sprint
1.4 - Structure of the Guide
This guide consists of:
• Introduction to Scrum: Explaining concepts such as: Scrum teams, events, artifacts, and related
rules.
• Scrum principles: Where we talk about 6 essential rules to ensure success in the application of
Scrum.
• Considerations for Project Management: Explaining the key elements to be taken into account
to ensure the correct development of the project.
• The life cycle of the project: This section is the heart of the guide, and it is here that explains how
to start up all the concepts learned, describing the key practices and their "logical order" in a real-
life project.
Each component within la Guide has A specific purpose and is essential for success In the adoption of
Scrum.
Illustration 1 -Structure of the guide

1.5 - Scrum uses
Scrum was initially developed to manage and develop products. However, its use is not Saw Limited to this
field, and over time the collected experience shows us that it is useful for:
1. Research and identify viable markets, technologies, and capabilities.
2. Development Of Improvements To existing products.

3. Development of products that require launches Daily Or As many times as possible.
4. Cloud development and maintenance (online, security, by-demand) and other operational
environmentsRoll for product use.
5. Maintenance and renewal of products.

6. Scrum has been shown especially effective in the transfer of knowledge iteratively and incrementally.
Scrum is widely usedo For The construction of Products And Services.
1.5.1-When to use agile methodologies?
Illustration 2 -Agile Methodologies vs cascade methodologies
1.6 - Guide clarifications
• In the development of this guide the term "product" refers to products, services and any other
deliverables that may arise as a result of a project exercise.
• When the concepts "development" and "develop" are used in this Scrum guide, they refer to the
development of the project's own activities, they are not limited to software development.
1.7 - Scrum Scalability
Scrum can be used in large projects regardless of the number of people O Activities to be developed, this
as long as you respect the rule of forming PequeñTeams of people, since this kind of Teams are very
Flexibles and adaptiveS
The strengths of The Equipment Scrum that allow its easy scaling are:
• Can Operatesr Individually In several, many, And even In Equipment Networks.
• Its multifunctional capacity allows Develop LAnzarOperatesr and maintainr Work and Product With
the least amount of dependencies possible.
• Collaboration and continuous interaction between teams and with the customer allows them to
DevelopedAr More architectures Sophisticated In the Development environments.
See more in the section 8: Scrum in big projects.
1.8 - is Scrum implemented or adopted?
The Scrum framework is more about a cultural change Throughout the organization That in simply
implementing The Tools Or techniques described here, so it's wrong to think about the "implementation"
of Scrum, the most appropriate thing is to talk about the "adoption" of Scrum, since it is necessary to
implement the proposed practices, to carry out experiments and to be continually adjusting the framework
to the changing needs of the organization.
For the Adoption of Scrum practices is required The support of the entire organization, this agile-oriented
culture is based on the simplicity, value and high performance needed for the management of modern
projects.
2. The Scrum Team
Illustration 3 -The Scrum Team
A Scrum team consists of a product owner, the development team and a scrum Master.
Scrum teams are Self and multifunctional. The Scrum Team model is designed to optimize flexibility,
creativity and productivity. The Scrum team has proven to be incrementally effective In different contexts
and PPlow any complex work.
Scrum teams deliver products in an iterative and incremental way, maximizing the opportunities to get
feedback. "Finished" product incremental deliveries ensure that a potentially useful and functional version
of the product will always be available.
2.1 - The Product Owner
Illustration 4 -Product Owner
The Product Owner is responsible for maximizing The value Delivered by The team of development.
The Product Owner is the only person responsible for managing The Product Backlog. The management
Product Backlog Includes:
• Clearly express the elements Product Backlog.
• Sort the items in The Product Backlog To achieve goals and missions in the best possible way.
• Ensure What The Product Backlog Visible, transparent and clear to all and showing, what the team will
work below.
• Ensure that the Development team Understands the elements Product Backlog At the required level.  
• The Product Owner He's a single person, not a committee. The Product Owner Could represent the
wishes of a committee in The Product Backlog, but those who want to change the priority of an element
ofL Product Backlog You must do it through the Product Owner.
For what The Product Owner Can do their job well, the whole Organization must respect their decisions.
Decisions DThe Product Owner are reflected in the content and prioritization Product Backlog.
The Product Owner is also responsible for:
• Participate in the opening and closing meetings of the project.
• Manage the project's global risks.

• Submit project reports to the customer or other stakeholders.
• Approve Project changes
• Ensure that the project's financial resources are properly managed at startup and during execution.
Normally the Product Owner is associated with a project manager, Given their management responsibilities,
although it is more necessary to associate it with the role it represents "The voice of the client."
2.2 - The Development team
Illustration 5 -The development team
The Development team It consists of professionals who perform the work of delivering a increase"Finished"
Product ment (Done) that Potentially can be put into production at the end of each Sprint. A "finished"
product increase is mandatory in the Sprint review (See section 3). Only members of the Development team
Participate In the creation of the increment.
The organization is in charge of structuring and empowering development teams to organize and manage
their own work. The resulting synergy optimizes the efficiency and effectiveness of Development team.
Development teams have The following features:
• Are Self. No one (not even the Scrum Master) tells the Development team How to convert items Product
Backlog In funcionalid incrementsAd potentially deployable.
• Nobody Out of the Scrum Master and Product Owner You can ask the development team to work on
a different set of requirements.
• Dev TeamsOllo They are multifunctional, with all the skills necessary for CRear a product increment.
• Scrum does not recognize titles for members of a Development team, regardless of the TRDown that
each person performs.

• Scrum does not recognize sub-teams in development teams, no matter the particular domains that
require consideration, such as testing, architecture, operations, or business analysis.
• The individual members of the Development team They can have specialized skills and areas where
they are more focused, but the responsibility lies with the Development team As a whole.
2.2.1 Size of the Development team
The optimum size of the Development team is from Between 3 and 9 Members, this allows you to be Small
enough to remain agile and large enough to be able to complete a quantity Significant of work.
• Have less than three members in the Development team Reduces interaction and results in
gainProductivity S smaller.
• Smaller development teams might find limitations on the skills required during a Sprint, making
the Development team Could not deliver an increase that could potentially be put into production.
• Having more than nine members on the team requires too much coordination.
• Large development teams generate too much complexity so that an empirical process can be
useful.
• Product Owner and Scrum Master roles are not counted on computer size calculation unless they
are also contributing To work in the Sprint Backlog.
2.3 Scrum Master (Scrum master)
Illustration 6 -The Scrum Master
Scrum Master is responsible for promoting and supporting scrum as defined in the Scrum guide. Their main
responsibility then is to ensure that All Know and apply correctly The theory of Scrum, Their practices and
Its rules.
• The Scrum Master is a leader Servant That is at the service of the Scrum Team.
• Scrum Master helps people outside the scrum team (Involved 6.1.1.2) To understand what
interactions with the Scrum team can be useful and which are not.
• The Scrum Master helps everyone modify these interactions to maximize the VAlor created by the
Scrum team.
2.3.1 The Scrum Master service to the Product ownero (Product Owner)
The Scrum Master serves To Product Owner In several ways, including:
• Ensure that the objectives, scope and dominance of the product are understood by all in the Team In
the best possible way.

• Find techniques to manage The Product Backlog Effectively.
• Help the Scrum team understand the need to have elements of Product Backlog Clear and concise.
• Understanding product planning in an empirical environment.
• Ensure that The Product Owner Learn how to order The Product Backlog To maximize the value.
• Understand and practice agility.
• Facilitate Scrum events as required or needed.
2.3.2 The Scrum Master service to the Development team
The Scrum Master serves the Development team In several ways, including:
• Guide the Development team To be selfOrganized and multifunctional.

• Help the Development team To create high value products.
• Eliminate impediments to the progress of the Development team.
• Facilitate Scrum events as required or needed.
• Guide the Development team In organizational environments where Scrum has not yet been fully
adopted and understood.
Illustration 7 -The Scrum Master Guide to the Team

2.3.3 The Scrum Master service to the organization
The Scrum Master serves the organization in several ways, includingNdo
• Lead and guide the organization in the adoption of Scrum.
• Plan Scrum implementations in the organization.

• Help employees and stakeholders understand and conduct Scrum and empirical product development.
• Motivate changes that increase the productivity of the Scrum team.
• Together with other Scrum Masters, Increase the effectiveness of the application of Scrum in the
organizationN.
2.4-The values of the equipment
It is important for the team members to generate and maintain a philosophy based on values that foster
trust, communication and results delivery. Next, the values that should exist in a Scrum team are related.
2.4.1 – Commitment
The commitment concerns each member of theEquipment will make the most effort Possible, it will also
put dedication to all the activities of the project.
2.4.2 Respect
Members of the EEquipment Scrum Respect the knowledge, skills and professional experience not only of
the other members of the team, but also of those people with whom they relate, whether their own
organization or another.
2.4.3 Proactivity
Proactivity allows team members to The Successful development of their work. This value is fundamental
to achieve good results in the changing environments to which agile projects are exposed, this value is not
limited to adaptability (Responding to change), proactivity is about initiating change.
2.4.4 – Receptivity-Opening
Scrum team members They must be open to learning new skills or acquiring new knowledge that Allow to
be teams Functional. This value is also related to transparency, collaboration and free knowledge.
2.4.5 – Focus
This principle wills will allow Scrum team members to focus on soWhat those activities Key that Allow Offer
the best product or service, the focus is on focusing on everything that is really important not only for the
project but also for the well-being of the team.
3. Events in Scrum
In Scrum there are different predefined events in order to Generate Regularity and minimize the need for
undefined meetings in Scrum.
All events are compartments or time-boxes, so that they all have a maximum duration.
3.1- The Sprint (Sprint)
The heart of Scrum is the Sprint, it is a time-box of 1 to 4 weeks During which a usable and potentially
deployable "finished" product increment is created.
Each new sprint starts immediately after the completion of the previous sprint.  The sprints contain and
consist of the Sprint Planning, the daily scrums, the development work, the sprint review, and the sprint
retrospective.
During the Sprint:
• No changes are made that may affect the Goal of the Sprint.
• The objectives of Quality do not decrease.

• The scope can be clarified and renegotiated between The Product Owner and the development team
as you learn more.
Each Sprint can be considered a project with a horizon of not more than one month. Like projects, sprints
are used to achieve something. Each Sprint has a goal of what will be built, a design and a flexible plan to
guide its construction, the team's work and the resulting product increment.
Sprints are limited to a calendar month. When the horizon of a Sprint is too big, The definition of what is
being built could change, complexity could increase, and the risk could increase.
Sprints enable predictability by ensuring inspection and adaptation of progress at least every calendar
month.
Illustration 8 -The Sprint

3.1.1-Considerations on the duration of the Sprint
• Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.
• The other events can end whenever the objective of the event is reached, ensuring that an
appropriate amount of time is used without allowing waste in the process.
• All Sprint-related events must run, LIn the absence of any of these events it results in a reduction
in transparency and constitutes a lost opportunity for inspection and adaptation.
• Within the same project, The Sprints can have variable duration (Keeping the rule from 1 to 4
weeks). The duration of the sprints It will depend on the following factors:
o Agreed delivery Dates
o Team experience (less experience with Scrum, sprints should be shorter)
o Project restrictions
• The duration of the Sprint is defined by the development team with the recommendations of the
Scrum Master, who in turn must reach a consensus with the Product Owner, usually this is done
during the definition of the schedule of deliveries (7.1.5).
3.12 Sprint Cancellation
An SpRint may be cancelled before The period Of time Come to an end. Some of the reasons you could
cancel a Sprint are:
- LA organization changes the address Of the project and that affects the deliverable of the Sprint.
- LAs market or technology conditions change.
- The goal of the Sprint was obsolete.
- An error arises about a product that is in production environment and the development team must
resolve it as soon as possible.
- There is an urgent change that must be introduced immediately.
Some considerations that should be Note on the cancellation of the sprints are:
- Only The Product Owner Has the authority to cancel the Sprint, although it can do so under the
influence of interested (7.1.1.2), from the Development team or the Scrum Master.
- DEcause to the short duration of sprints, their cancellation rarely makes sense.
- When a Sprint is cancelled, all the items are checked Product Backlog that have been completed
and "finished". If a part of the job is potentially deliverable, The Product Owner He usually accepts
it.
- All the Elements Product Backlog Not completed are re-estimated and re-entered into The Product
Backlog. The work done on them loses value quickly and should usually be re-estimated.
- Sprint cancellations consume resources as everyone regroups into another sprint planning to start
another sprint.
- Sprint cancellations are often traumatic for the teamOr Scrum and they're very rare.
3.2 – Meeting of Planning of the Sprint
- In this event we plan the work to be done during a Sprint.

- This plan is created through the collaborative work of the entire Scrum team.
- The Scrum Master ensures that the event takes place and that the attendees understand its purpose.
- The scrum Master teaches the scrum team to stay within the time period.
3.2.1 Event data
- Duration: 2 hours per week of Sprint to plan. (maximum duration of eight hours).
- Participants: All Scrum Team (Section 2).

- What do you do at the meeting?
o 1. What can End In This Sprint?

▪ 1.1 – Changes are identified What Should be introduced in this Sprint (Section 6.4).
▪ 1.2-Select the elements of the Product Backlog.
▪ 1.3 – Identify tasks to be executed to "terminate" those items.
▪ 1.4 – Identify dependencies that may exist.

▪ 1.5 – The estimation of the elements selected for their development is made.
▪ 1.6 – The development team autoallocates the elements of the Product Backlog.
o 2. How will you manage to complete the selected work?
▪ 2.1 - What risks will this Sprint affect? (Section 6.3)
o 3. Formalize the goal of the Sprint
▪ The goal of the Sprint is reflected in the Sprint Backlog (Section 4.2- Sprint Backlog)
3.3- Daily Scrum (daily scrum)
The daily Scrum is a meeting with a time block of 15 minutes for the Development team. Daily Scrum is
performed daily for each sprint day.
3.3.1-Event data
- Duration: 15 minutes tops.

- Participants: The development team and the Scrum Master
The development team answers the following questions:
o What did I do Today?

o What will I do Morning?
o ¿Exists Some impediment that is affecting or may affect us?
- During the daily Scrum The Development team He's planning the job for the next 24 hours.
- The Daily Scrum OrPtimiza Collaboration and Performance Of the team by inspecting the advanced
work from the last daily Scrum and projecting the work to be done next.
- The development team or team members are often reconvened immediately after the daily Scrum,
to have detailed discussions, or to adapt or re-plan the rest of the Sprint work.
- The daily Scrum is done at the same time and place every day to reduce complexity. It is usually
done before the end of the working day of the development team.
- The Development team Use the daily Scrum to evaluate the progress towards Goal of the Sprint.
- The daily Scrum optimizes the chances that the Development team Meet the Goal of the Sprint.
- The Scrum Master ensures that the Development team Have the Meeting But it is the development
team responsible for managing the daily Scrum, ie, is not obligatory the presence of the scrum
Master to carry out the daily scrum.
- The Scrum Master Teaches The development team to keep the Scrum daily at the time block limits
of 15 minutes.
- The daily Scrum is an internal meeting of the Development team. If other people are present, the
Scrum Master makes sure they don't interrupt the meeting.
- The daily Scrum improve communication, eliminate the need for other meetings, identify
impediments to removers related to development, highlight and promote rapid decision making
and improve the level of knowledge of Development team.
- During the daily scrum the Burndown chart and the scrum Board are updated.
- This meeting is usually done standing in order to ensure the fulfillment of the allocated time, so
you can also be known as the daily Scrum standing (Daily Standup Meeting).
3.4 – Meeting of Sprint Review
At the end of the sprint a sprint review is conducted to inspect the increment and adapt The Product Backlog
If necessary. During the Sprint review, the Scrum team and the stakeholders collaborate on what was done
during the Sprint. Based In this and any changes toL Product Backlog During the Sprint, attendees
collaborate to determine the following things that could be done to optimize the value. This is an informal
meeting, not a follow-up meeting, and the introduction of the increase aims to facilitate information
feedback and encourage collaboration.
The Scrum Master ensures that the event takes place and that the attendees understand its purpose. The
Scrum Master teaches everyone to keep the event within the fixed time block.
3.4.1 Event data
- Duration: 1 hour for each week of Sprint to review. (maximum duration of four hours).
- Participants: All Scrum Team (Section 2) + Interested partiess Key to be invited by the Product
Owner
• The Development team Talk about what was right during the Sprint, what problems appeared
and how FUeron solved those problems.
• The Development team It makes a demonstration of the work that has "finished" and responds
PUestions about the increment and its functionality.
• The Product Owner Talk about the Product Backlog in its current state. Projects probable
targets and time delivery dates based on progress to date (if necessaryRIO).
• Product Owner carries out the approval of the elements of the product Backlog What have
been "terminated" and rejects those that have not been "terminated" and with this determine
the technical debt.

• The Team Complete collaborates on what to do next so that the Sprint review provides valuable
input information for subsequent sprint planning meetings.
• Review of chronology, budget, potential capacities and market for the next expected delivery
of the product.
The result of the Sprint review It is a revised Backlog Product that defines the elements Product Backlog
Possible for the next Sprint. It is also possible that The Product Backlog Receive a general adjustment to
focus on new opportunities.
3.5 – Sprint Retrospective meeting
The main theme Of the Sprint retrospective meeting Is the identification of possible improvements that can
incorporateR the team in upcoming sprints.
3.5.1-Event data
- Duration: 1 hour for each week of Sprint to review. (maximum duration of four hours).
- Participants: Development team and the Scrum Master (It is not recommended that the Product
Owner be part of this meeting).

• To inspect how the last Sprint was in terms of people,Processes and tools.
• Identify and order the most important elements that came out well and possible improvements
That can incorporate the team in upcoming sprints.
• Create a plan to implement the improvements to the way the Scrum team performs their work.
4. The Artifacts in Scrum

Scrum artifacts represent work or value in a variety of ways that are useful for providing transparency and
opportunities for inspection and adaptation. Scrum-defined artifacts are specifically designed to maximize
the transparency of key information needed to ensure that everyone has the same understanding of the
artifact.
4.1- Product Backlog
The Product Backlog It is an orderly list of everything known to be necessary in the product and is the only
source of requirements for any changes to be made to the product. The Product Owner is responsible
Product Backlog, including its content, availability and management.
A Product Backlog Never completeo. The earliest development of the same It only reflects the known and
best understood requirements at first.
The Product Backlog Evolves as the product and the environment in which it will be used also do so. The
Product Backlog Is Dinámico; It constantly changes to identify what the product needs to be suitable,
competitive and useful. As long as the product exists, your product Backlog also exists.
The Product Backlog Lists all the features, features, requirements, improvements and corrections that are
changes to be made on the product for future deliveries. The Elements Product Backlog They have at least
the following attributes:
• Description (depending on business value)
• EL Order Priority
• The estimate
• Acceptance criteria
As a product is used and increases its value and the market provides feedback, The Product Backlog It
becomes a longer and more exhaustive list. Requirements never stop changing so The Product Backlog It's
a live artifact. Changes in business requirements, market conditions or technology may cause changes in
The Product Backlog.
¡IMPORTANT NOTE! To avoid projects that never end, it is important to consider the scope of the project
when it comes to refining the Product Backlog.
4.2- Sprint Backlog
The Sprint Backlog Is the whole of the elements Product Backlog Selected for A Sprint, plus a plan to deliver
the product increment and get the goal of the sprint.
The Sprint Backlog It is a prediction made by the Development team about what functionality will be part
of the next increment and the work needed to deliver that functionality in a "finished" increment.
When new work is required, the Development team The AdiciOna aL Sprint Backlog. As the work is executed
or completed, the remaining work estimate is updated. When some element of the plan is considered
unnecessary, it is eliminated. Only the Development team You can change your Sprint Backlog During a
Sprint. The Sprint Backlog is a real-time visible picture of the work that the Development team Plan to
perform during the Sprint and belongs only to the Development team.
• The sprint Backlog makes visible all the work that the development team must complete to reach
the goal of the sprint.
• To ensure continuous improvement, In the Sprint Backlog Is Includes For what least one Activity
that allows the Process Improvement (usually Identifieds In the retrospective immediately
preceding).
• The Sprint Backlog is a plan with a sufficient level of detail so that changes in progress can be
understood in the daily Scrum.
4.2.1 Increase
A Increase is the sum of all the elements Product Backlog Completed during a sprint and the value of the
increments of all previous sprints. At the end of a Sprint the new increment must be "finished", which means
that it is in a position to be used and that it complies with the definition of "finished" equipment Scrum.
• The increase is a step towards The Vision or goal of the project.

• The increment must be able to be used regardless of whether the Product Owner decides to release
it or not.
4.3- Information issuers
The emitters of Information They are artifacts that allow you to graphically display the status of the sprints
or dThe project in general. They serve to ensure the transparency and to track and control the project
(Section 6.2).
4.3.1 Scrum Board
The scrum board or also known as scrum board It is an adaptation of the Kanban board that allows us to
follow up each Sprint Backlog within a Scrum project.
The scrum Board is an information emitter that allows the team to ensure transparency in the sprints,
maintains coordination and allows the scrum Master to perform its inspection tasks. (Section 5.1)
It is composed of 4 columns: Pending, in progress, in Test (in Review), "finished".
Each item to be developed must be placed on an indi-Bed, and since the Scrum Board is constantly updated,
all cards must pass through the 4 columns. (column skipping is not possible).
Illustration 9 -Scrum Board
Scrum Board Clarifications

• When the board is physical in the work place of the equipment, usually the cards that are handled
They're sticky notes of different colors.
• When you are going to develop multiple user stories in a single Sprint it is advisable to divide the
board into rows, where each row represents a component or epic of the product.
• At the end of a Sprint "clears" the Scrum Board
• To consider "finished" an item and move it to this area in the Scrum Board, consider the "definition
of terminated (DoD)" (Section 7.1.1.3).
• To facilitate the reading of the Scrum Board, each member of the team can assigned a card color.
• Although the Scrum Board is usually updated during the daily meeting, each member of the
development team has autonomy to update its set of items assigned in the Sprint Backlog.
4.3.2 BurndOwn Sprint Chart
The "Burndown Chart" is an information emitter that shows the amount of work Slope That's left in the
current Sprint.
It is a 2-dimensional graphic emitter:
• The vertical axis is built from the summation of history points to be developed in the Sprint
• The horizontal axis corresponds to the duration of the Sprint on weekdays.
Illustration 10 - Burndown Sprint Chart

Clarifications on the Burndown Chart
• A possible variation is the Burnup chart showing the work completed in the Sprint
• The development team is responsible for updating the Burndown Chart
• Usually the update is done during the daily Scrum.
4.3.3 – Cumulative Flow chart
The DAccumulated Flow Iagrama (CFD - Cumulative Flow Diagram) is a Sender of Information Pretty Useful
for the elaboration of reports and the monitoring of the results of the project.
This information emitter shows the progress of the project with respect to the items of the Product Backlog.
Illustration 11 -Accumulated flow Diagram
• The "Grey" zone shows the behavior of the Product Backlog.
o increments mean adding new user requirements/tasks/stories.
o Decrements mean the removal of user requirements/tasks/stories that no longer generate
value (change product).

• The "blue" zone shows the work that was selected by the team to develop in the different sprints.
• The "green" zone shows the work done in the project around the time.
o When the Blue Zone is above the Green Zone, it usually means that the team selected more
work than it could finish, this is known as "technical debt."
o The difference between the "green" zone and the "Grey" zone is related to the progress of
the project.
• The points marked in the graph show the different sprints.
• The vertical axis could be the "size of requirements", this would be more accurate when calculating
the progress of the project.
• The cumulative flow diagram is unique per project.
• The technique was originally from the Kanban methodology.
• The person in charge of This information radiator is the Scrum Master, although normalNte is the
Product Owner who Used to show the progress of the project to the stakeholders.
4.4 – Obstacle/Impediment Registration
The registration of obstacles, or also called Registry of Impediments is an artifact in which all the obstacles
that are presented in the projects and their respective solution are recorded.
This artifact is the responsibility of scrum masters and is usually updated during daily scrum.
In some organizations this artifact is global for all projects and serves as a knowledge base for all members
of the various Scrum teams.
5. Principles of Scrum
Scrum defines 6 principles that are key to the smooth working of the framework. You can make sure that
sOn the “Rules” To know and apply the Members Of EEquipment Scrum to ensure the proper functioning
of this framework.
5.1 - Empirical Control of processes 1
Scrum is based on the theory of control Empirical of processes or empiricism. Empiricism ensures that
knowledge comes from experience and decision-making based on what is known. Scrum employs an
iterative and incremental approach to optimize predictability and risk control.
The 3 Pillars What Support the entire implementation of the control Empirical of processes Are:
Transparency, inspection and adaptation.
5.1.1 Transparency
The significant aspects of the Project should be visible to Stakeholders. Transparency requires that these
aspects be defined by a common standard, so that observers share a common understanding of what is
being seen.
For example:
• TParticipants should share a common language to refer to the process of.
• Those who perform the work and those who accept the product of that work must share a common
definition of "terminated."
5.1.1.1 Transparency of artifacts
Scrum is based on transparency. The decisions to optimize the value and control the risk are taken based
on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a
solid basis. To the extent that artifacts are not completely transparent, these decisions may be erroneous,
the value may decrease and the risk may increase.
The Scrum Master must work with the Product Owner, the Development team and other parts Interested
To understand if the artifacts are completely transparent. There are practices to cope with the lack of
transparency; The Scrum Master should help everyone apply the most appropriate practices if there is no
complete transparency.
A Scrum Master can detect the lack of transparency by inspecting the artifacts, recognizing patterns,
listening carefully to what is said and detecting differences between the expected results and the real ones.
The work of the scrum Master is to work with the scrum team and the Organization to improve the
transparency of the artifacts. This work usually includes learning, conviction and change. Transparency does
not happen overnight, but it is a path.
5.1.2 Inspection
In the Scrum projects Should inspect FREcuentemente Artifacts and progress toward a target, to detect
variations.
The Inspection should not be so frequent as to interfere in the work, lAs inspections are most beneficial
when carried out diligently by expert inspectors In the same workplace (usually the Scrum Master).
5.1.3 Adaptation
If an inspector determines that one or more aspects of a process deviate from acceptable limits, and that
the resulting product will not be acceptable, the process or material being processed must be adjusted. This
adjustment must be done as soon as possible to minimize major deviations.
Scrum prescribes four formal events, contained within the Sprint, for inspection and adaptation, as
described in the events section Scrum of this guide:
• MeetSprint Planning.
• Daily Scrum.
• Sprint Review.
• Sprint retrospective.
5.2 – CarOrganization 2
For Scrum, the development team must be self-organized, this means that they are the team members Who
They choose the best option to carry out their Work Without being Directed by people outside the team.
To Then The rules that guarantee the self-organization of the team are listed:
• The development team is the one who autoallocates the work to be done in the different sprints,
nobody, not even the Product Owner should impose the work on the team.
• The team must know their decision limits very well in order to have greater autonomy.
• The team must have spaces that allow them to carry out research and training days.
• The equipment must Stay Motivated.
In order for a team to be self-organized, the following elements are required at least:
• There must be a formally defined goal and knowledge for the team, "if the team does not have a
defined course, it will not know where it should go and it is impossible to organize itself."
• The equipment mustNtender the vision of the project and why the project adds value to the
organization.
• Transparency and inspection are essential for a self-organized team.
• The team members must be multifunctional, as well as updating Your knowledge and skills on a
continuous basis.
5.2.1 Team collaboration
The collaboration is given thanks to the constant communication that exists in the Scrum teams, both
between theirS members as with the parties INteresadas of the project, this concept is an integral part of
the Agile Manifesto "The most efficient and effective way to transmit information to and within the
development team is face-to-face conversation. "
Scrum Master is the responsible role Of Ensure a healthy communication between all stakeholders of the
project, especially its development team.
should be considered What Depending on the nature of the project, the needs of the organization and even
external factors determine the location of the team members. That's why In Scrum the teams They are
classified into 2 categories:
5.2.1.1 Centralized equipment
The characteristics of a centralized team are:
• Team members are in the same location, allowing them to communicate very easily.
• Problem solving is almost immediately Being located in the same place is easy to perform di
sessionsáLogo.
5.2.1.2 Distributed computers
A distributed computer with is located in the same location, it is usually Dispersed due to subcontracting,
different physical locations, work options from home, etc.
To ensure permanent communication in this type of equipment, the following tools are required:
• Groupware.
• Software Videocalls or chat.
• Software of Management of Projects Agile.

• HSoftware erramientas that simulate Scrum functionality Boards.
5.2.2 Customer Collaboration
In traditional projects, the customers Usually Were kept at a distance and soIt is InvolucrabAt the beginning
and end of the Project. In Scrum Es highly recommended that the customer ParticipE of Product Reviews
And Provide feedback At all points of "inspection and adaptation". This minimizes risk andMore options to
the customer and theS Interested partiesS
By Example In other agile frames like XP, it is compulsory for the client to be part of the team.
The customer (or their representatives) should work withL Product Owner To define The User stories and
detail those stories Before or During the planning meetings.
The customer and stakeholders usually participate in the review meeting Of all the SPrint and depending
on Of The relationship between the client and the Product Owner, the customer I could even participate in
some meetings of REtrospectiva lOS SPrint.
Illustration 12 -The client participates in the Agile project
5.23 Multifunctional equipment
Multifunctional teams have all the skills and abilities necessary to carry out the work without relying on
other people who are not part of the team.
Contrary to what a multifunctional team thinks, It is not that all its members do everything, it is that the
members acquire knowledge in different disciplines (applicable to the projects of the organization) and
thus can contribute effectively with the collaboration.
The reality is that even when A Team be technical expert, always NECEsitarán additional training, so the
Product Owner must Decide If Approve Money and time to train Or On the contrary they will be Team
members WhoIs will take care of the topic (Section 6.1).
5.2.3.1 – Managing Knowledge
Perform this exercise Allow To identify, collect, organize, transfer and retain the Knowledge necessary to
support all staff in their work activities, to make well-founded decisions and to increase productivity.
5.2.4 Collective ownership of the product
In order to ensure a constant collaboration and avoid over time the emergence of a culture of guilt, it is
important to promote a collective ownership of the product, this means that the whole Scrum team owns
the product, and therefore any of its members It could contribute to the development of any part of the
product even if it was not the one who developed it initially.
Also there should be no individual recognition to team members by SUS contributions to the product.
5.2.5 – Team Motivation
Scrum teams are characterized by maintaining a focus on frequent delivery of results; And although the
team members are aware of the responsibility that this implies, there is a fundamental factor that facilitates
the momentum and effort to meet the objectives; lTo mOtivación.
The motivation refers to the members of the team to maintain a certain behavior and state of mind that
promote the healthy interactions and the high performance in the project.
Types of motivation
• Intrinsic: This type of motivation is characteristic of each person, that is to say that by his own will and
inspiration he is able to maintain a specific behavior and the impulse necessary to fulfill a goal that
provides internal satisfaction and personal fulfillment.
• Extrinsic: This Type of motivation refers to maintaining a specific behavior to respond to an external
impulse, ie in this case the will and inspiration of the person are influenced by an external reward (which
can be something physical, monetary or psychological) .
Depending on how the motivation is handled in the Scrum team, eventually the extrinsic motivation
tends to become intrinsic motivation, as the team members adapt their behavior and improve their
performance to meet the goals without having to All the time they're getting rewards or something in
return.
Identify the motivators

When we talk about motivation, is the scrum Master who will have the greatest participation and
responsibility because being at the service of the scrum team can easily identify what is what increases or
decreases the motivation of team members; This is why within the tasks of the Scrum Master is included
the identification and analysis of the motivating elements of the team to build and develop a motivation
Plan that will later negotiate with the Product Owner to ensure the necessary resources For execution.
Encourage research
Within the set of factors that increase the motivation of the team in Scrum it is recommended to encourage
the research of new products or technologies which favors that the members of the team acquire new
knowledge and incline towards the achievement of new Objectives.
The research will also encourage team members to set goals based on self-realization and development of
their own competencies.
Some methodologies in the market talk about the techniques that can encourage research in the teams,
such as: Demodaly – HEnkathon – Exploration days – TED days, etc.

5.3 – Simplicity 3
Scrum would not be considered a ág methodologyIl if not for its simplicity, that is why it tries to the
maximum reduce the bureaucracy in its practices, it works with the artifacts that are essential for the Project
and follows a simple flow of practices, without neglecting all the necessary elements for the correct
management of the project.
• It is the responsibility of the scrum Master to ensure that simplicity will be the cornerstone for the
adoption of scrum.
5.3.1 Simple design
The most important thing in the Development Of A product using the mScrum arc is the value that it gives
to customers/users, considering that its development should take as little time as possible.
That is why it is highly advisable to establish a scope for the project that considers sufficient characteristics
to make the product high value for the user but has the least possible development time, without neglecting
the quality.
This concept has its justification in the principles of the Agile Manifesto "The functional product is more
important than the exhaustive documentation". (See more in the Section 6.5)
5.3.2 Using software tools
Software tools for Agile project management have beenn Become an indispensable element to ensure the
simplicity. AOme of the advantages of using these tools are:
• They centralize the information of the projects, allowing a better control of the information.
• Allow you to automate tasks, for example:
o Historical-based estimates.
o Calculate Team Speed.
o Develop charts for budget tracking, Sprint progress (Burndown), project progress
(cumulative flow chart), etc.
o Generate Meeting Minutes.
• They generate notifications about elements of the Product Backlog with delay.
• Facilitate the interaction of geographically distributed equipment.
• If the projects are software development, Allow In addition:
o Continuous integration.
o Automated testing.
o Bi-directional traceability between code and user stories.
5.3.3-Is it worth working with processes?
Although in many organizations working with processes is seen as a great advantage because it ensures
the good performance of its collaborators, when we talk about agile projects, we will have to see the
situation from another point.
The organizations have models of operation that tend to behave in a "static" way, in which we usually find
a structure of hierarchies and bureaucracy, where in a routine way the collaborators know the
products/services of the Organization and know how to operate on a daily basis to ensure its proper
delivery; However with the projects it is not always the same because the members of the project team are
often faced with new challenges that drive them to constantly change and take autonomous behavior in
certain situations.
On the other hand, we see that organizations can easily perceive the benefits of processes (they facilitate
quality reviews, staff induction, audits, etc.) as long as these processes are implemented and do not remain
as Simple documents, as they alone do not bring value to the organization. This premise applies as is, to
agile projects, because when we talk about processes in projects we must maintain a focus on practice
(which are internalized and naturally executed by all members), maintaining a healthy balance between the
Typical organizational bureaucracy (which disfavors agility) and anarchy (which decreases credibility in the
team). When you meet and keep the midpoint between These Two, the team is in an environment of agility:
without absolute bureaucracy and without absolute anarchy.
Illustration 13 -balance between bureaucracy and anarchy: agility

5.4 - Focus on Customer Value 4
In a Scrum project, lAt top priority is to satisfy the customer from the start and continually EntregánDole
the maximum possible value, for which it is important to consider the following aspects:
• It is important that in each one of the sprints Product increments are generated that Delivered
Value for the client and these in turn are "finished".
• To make the prioritization of the elements that are part of the Product Backlog the Members Of
the Scrum team should consider mainly the value that the element can generate, for this is
important the concept of transparency (Section 5.1.1).
• Each "finished" product increment must be validated with the customer to ensure feedback
collection.
• is highly Important That the customer actively participates in product prototype reviews before
Perform any development; IVen and depending on the nature of the project, the customer can
actively participate in the design of the product.
5.5 – Compliance 5
Complying with the rules established by the Scrum team and the organization is of vital importance to
ensure healthy coexistence among all members of the scrum team, avoid deviations in the projects And By
Last But no less important, to ensure customer satisfaction.
The essential rules to be fulfilled are listed below:
• Rules established by the Scrum team.
• Rules established by the organization.

• Time blocks allocated to Scrum events.
• Definition of termination and acceptance criteria.
5.5.1 Time blocks
The time blocks allocated to Scrum events ensure that no time is wasted on projects. Some Advantages Of
Respect the blocks of thePo assigned are as follows:

• The team is prevented from losing motivation.
• Less overhead For the project.
• One guarantees aLTA Speed for equipment.
• Practices related to the development of deliverables are more EfficientS
5.5.2 Team rules
Thanks to the principle of self-organization, are the members of the Scrum team, who establish their own
rules, of course, considering compliance with the rules established by the organization. Usually, these rules
are set only once at the start of the project, and may sometimes be global for multiple projects or multiple
teams. The artifact where these rules are recorded is often called "Scrum team collaboration Plan".
Some of the items that can be part of the Scrum team collaboration Plan are:
• Team Principles.
• Communication tools.
• Meeting Schedules.
• Penalties for non-compliance.
5.6 - Iterative development 6
Scrum was designed to make the project develop POr iterations, also knowns like sprints. The iterative
method is flexible and open to changes, This allows the project to be adapted to the changing needs of the
market, the client or the organization.
Each iteration is composed of the following stages of the project lifecycle and their respective practices:
• Stage 2: Planning.
• Stage 3: Sprint Development.
• Stage 4: Sprint review.
• Stage 5: implementation.
This means that the following steps have practices that are not necessarily iterative:
• Stage 1: Start of the project.
• Stage 6: Closing of the project.
6. Considerations for The Management DThe PProject

6.1 - Hiring
6.1.1 - Roles of the project
People take a key role in project management Agile, their participation is given through the set of
responsibilities assigned to them, i.e. their role in the project. A Scrum project is considered to be 2
Classification categories for Roles:
6.1.1.1 - Committed
The Committed Are the Roles What Necessarily are required to produce the project product, Therefore
are responsible for the success of each ITerai of the project and the project itself.
The roles involved are:
- The Product Owner.
- The Scrum Master.
- The development team.
6.1.1.2 - Involved
The Involved sOn the roles that are not necessarily necessary for the Scrum project. They can interact with
the team, but No They are responsible for the success of the project.
The roles involved are:
- Customers.
- Users.
- Suppliers (ex: Freelancers; Service providers; etc).
- Office of Agile Project Management (APMO).

6.1.2 - Hiring of the team Personal
To Then Some of theS Requirements That should be considered for the assignment/hiring of the people to
occupyán the different roles in a Scrum project.
Product Owner Scrum Master Development team
-Scrum Expert
-Extensive experience and
mastery of business -Scrum Expert -Basic knowledge of Scrum

-Good negotiator -Problem Solving ability -Technical Experts
-Organized -Coordination Skills -Multifunctional
-Experience in project -Helpful leader -Proactive
management
-Helpful leader
Illustration 14 -Scrum Team Skills
6.1.2.1-The helpful leaders
The helpful leaders have several features that allow them to support the development team:
• Listening Ability: Listen to men With attention and Are Receptives To what is said and not said to
understand and reflect on the situation.
• Empathy: ToCeptan and recognizesn Individuals for their unique skills and abilities.
• Persuasion: Achievedn The consensus of the Team In the Making of Decisions.
6.1.2.2- Matrix of Competences
The Matrix of Competences Allows The organization Identify the necessary competencies in the Members
who make or will be part of the different teams and thus find any gaps that may exist in Team members
ScrumAnd thus also be able to identify The Members Who will need additional training in a specific area or
competence.
Illustration 15 – Competency Matrix
Although generally for the hiring of the team members is made based on the knowledge or technical skills,
in Scrum it is recognized that it is also necessary that the members of the team have other types of skills
that will allow him to develop Best interactions, better communication and greater cohesion. The needs of
the Scrum team, are taken as additional criteria to take into account for the proper hiring of the members:
Illustration 16 -Equipment needs
6.1.2.3- Development Team Roles
It is often thought that In multifunctional equipment there can be no roles or specialists, being this totally
false statement, usually a team is composed of different specialists such as:
• Analysts.
• Developers.
• Testers.
• Integrators.
• Designers.
• Architects.
• Etc.
Hiring newbies or experts?
If The Goal is to finish the project in a short time and with very high CaliTechnical experts, considering that
this will have an IMSignificant cost pact; On the other hand you could hire soWhat nOvatos, but the project
will take a long time to develop Because of the learning curve, in addition the quality It could be
compromised.
Make a combination of nOvatos and eXpert, can discourage To the experts, Although It can also occur The
situation in the For newbies to grow fast and achieve balance Expected.
6.1.3 - Types of contracts

Fixed price contract
• A fixed total price is defined for everything that is developed in the project.
• Increased financial risk if the entire project is not enforced according to the contract.
• The deliverables are fixed and defined at the beginning of the project.
• are not ideal for the use of Scrum.
T-Union contractEmporal
• It is usually used when two or more partners run a project.

• ROI (income or benefits) will be shared among all partners.
• It is important to define the% of partParticipation and responsibilities in the project.
• It is ideal to centralize the equipment or to divide the project into components.
Phased development contract
• The concept of a Viable minimum product is considered.
• The project is "fragmented" in several phases, where at the end of each phase Payments are made.
• Each phase generates an important set of deliverables.
• Useful for large-scale projects.
• Monetary risk is reduced, as unsuccessful deployments are not financed.
Incremental delivery Contract
• The client/sponsor can make decisions about the project in each inspection: it can accept the
deliverable, stop the development or request modifications.
• Each Sprint must generate an increment usually is an epic or full component.
• Payment/billing is done with each iteration (usually used in internal projects).
• It is also He calls it "sprint contract."
6.1.4 - Project Finances

6.1.4.1- Initial project budget
One of the key practices In Scrum is the construction of the Initial project budget, for which the following
elements must be taken into account at least:
• People who will be part of the project.

• Materials.
• Services.
• Infrastructure.
• Team Training.
• Reservations.
• Other expenses that affect the development of the project.
Note: It is the responsibility of the Product Owner and the project sponsor to discuss, negotiate and accept
the budget to ensure that there are sufficient funds available for the project.
Some of the techniques and tools that can be used to manage the finances of the project are:
6.1.4.1.1- Return on investment
Illustration 17 -Formula for the calculation of the ROI
6.1.4.1.2- Historical-based estimation
The historical data of the same project or other projects will be very useful for logRAR Best estimates of the
elements that are part of the Product Backlog.
Depending on the information available in the organization, You can Use:
• Historical history of previous projects: This technique will work As long as the organization keeps
track of the actual effort and duration of the project (the most advisable technique In Scrum).
• Historical plans: En those with an original estimate, even if the actual data (the most common
technique) has not been tracked.
6.1.4.1.3- Business knowledge coefficient
This technique is based on the idea that the more knowledge of the business/project, the more accurate
the budget estimate will be. Less knowledge of the business/project, there will be greater risk and less
precision in the estimation.
The objective of this technique is to calculate in a percentage scale the degree of knowledge about the
business and from there calculate the financial or budget reserve.
Some factors for calculating the coefficient of knowledge about business are:
• Experience in similar projects.
• Quality of initial project requirements.

• Degree of risk to which the project is exposed.
• Deviation (%) in project estimates.
6.1.5 -Hiring of suppliers
To ensure that Works with The best suppliers, The selection It is done considering the opinions of the whole
Scrum team.
Some of the criteria that Can be Consider for the selection of suppliers are:
• Price.
• Learning curve.
• Ease of Use.
• Solution Speed.
• Support.
• Security.
• Complexity for data migration.
• Implementation time.
• Reputation.
• Ease of payment.
• References.
6.1.6 TheFReelancers "
In some projects, it may be necessary to support staff not available in the development team, for example
"architects", "designers", "Database Administrators"Etc.
This type of Personal is considered as a provider, and usually soIt is hired for days, and in very specific
moments of the project.

Illustration 18 -Freelancers
6.2 - Monitoring and control Ofl Project
The monitoring and control of the project is an activity that must be done continuously throughout the life
cycle of the project. Usually the moments where it is done in an intensive way are: At the beginning, at pre-
defined intervals during the project or at any time when problems or risks of viability arise.
6.2.1 - Office of Agile Project Management (APMO)
A APMO is formed by a group of experts In Scrum or other agile frameworks.
The Office of Agile Project Management (APMO) has as responsibilities:
• Study the feasibility of project initiatives.
• Generate Support Guides.

• Provide advice To the different Scrum teams in the organization.
• Give isGuimiento to Projects.

• Report to top management.
• Keep your project portfolio up to date.

• Define the "CRites of Completion” Global Organization (See Section - Definition of finished DoD).
• Usually takes care of guiding the project retrospectives.
• Ensure the correct management of lessons learned of the projects.
• It does not make decisions about the projects, but it works as a consultancy, advice or guidance
support for all projects, programs and portfolios. Of the organization's projects.
Illustration 19 -APMO Activities
6.2.2 Project reports and reports
At any time it is possible to To know the progress of the project with only Add the remaining total work to
achieve the goal. The Product Owner keeps track of this total remaining work at least in each Sprint review.
The Product Owner compares this amount with the remaining work in previous Sprint reviews, to evaluate
progress toward completion of projected work at the desired time for the target. This information is shown
in a transparent manner to all stakeholders.
Several trend-projection practices have been used to predict progress, such as Burn Down, work completed
(burn Up) and accumulated flow (Cumulative flow). These have proven to be useful, sHowever, they do not
replace the importance of empiricism. In complex environments it is not known what will happen. Only what
has already happened can be used for decision-making with a view to the future.
6.2.21 Speed of Scrum Team
The speed of the Team is the speed With The Can't teame Complete the job in a Sprint. It is usually expressed
in the same units as those used for the estimation, usually points of history.
• All The teams have different speed, so they are part of the same project.
Below, The formula for calculating the speed of a Scrum team:

Illustration 20 -Scrum Team Speed
6.2.2.2 -Metrics in Scrum projects
Some of the metrics that are really useful when working using Scrum are:
Metric What is measured? What is it used for? Responsible Frequency
Completed User Stories
• Monitor Team Progress.

Accumulated
Pending User Stories • Avoid team technical debt in each Scrum Master Sprint
flow
sprint.
User Stories in progress
Product
Project costs Monthly project costs Reduce the risk of detours Financial. Month
Owner
Number of history points

Find the balance point of the work that the
Team Speed that the team can end up in Scrum Master Sprint
team can commit to in each sprint.
a Sprint
Development
Prevent the team from having problems or
Impediments TyFixed impediments AD Team/Scrum Sprint
delays in the next sprint.
Master
# Changes Accepted
Guarantee the stability of the projects and

# changes rejected Product
Changes ensure that the changes are taken care of in Weekly
Owner
time.
# Pending Changes to
review
Unit Test Errors
Mistakes in peer testing

Development
Errors Guarantee the quality of the product. Sprint
team
Production failures
Errors in validation
Materialized risks
Guarantee the quality of the product and the Product

Risks Mitigated risks Sprint
stability of the project Owner
Untreated risks
6.2.3 -Quality tracking
In Scrum, quality is defined as the product's ability to meet "Terminated" criteria and reach the value that
the client expectsE. In Scrum projects it is extremely important to keep track of the quality of the product
and avoid problems in the future (this is an iterative practice that is done in All The sprints).
6.2.31 Quality Control
Quality Control refers to the execution of quality activities That are made to the product increments that
are potentially ready for delivery And then on the product.
Normally the quality controls are carried out by the development team and the Scrum Master during the
sprint development practice, and by the Product Owner in the sprint review.
6.2.32 Quality Assurance
Quality assurance refers to the evaluation of the processes and standards that Are The definitionos in the
life cycle of a Scrum project.
Quality assurance is usually done through process audits carried out by the APMO (Section 6.2.1).
For Carry out the activities of Quality assurance, Can Use the framework for the evaluation and improvement
of information technology processes (MEMPTI).
6.3 - Management of Risks
The management of Risks It is an activity that is done Proactively and through the life cycle of the project.
• A risk is defined as an unexpected situation that can affect the goals of a project.
• Risks can have both a positive and a negative impact on the project.
6.3.1 Examples of common risks:
- Lack of capacity of the current human resource
In some organizations, the personnel available for the execution of the projects have assigned other
responsibilities that prevent him to have total availability to execute the activities of the project.
Some of the possible actions to take are:
- Plan the activities of the current staff.
- Avoid urgent changes as much as possible.

- Consider the hiring of external staff or suppliers that can contribute to the execution
of the projects.
- Lack of monitoring and control over projects
The lack of monitoring and control of the portfolio of projects can cause obsolescence and/or failure.
Some of the possible actions to take are:
• Use a tool to monitor and control the projects.
• Perform an update Ongoing portfolio of projects, to confirm the delivery of value.
• Monitor the schedule and budget of each project.
- The budget is exhausted or not enough
It should be considered that for the development of the majority of the projects Internal, it is They need
considerable sums of money, which must be projected into the general budget of the organization.
- Lack of commitment on the part of those involved in the projects
The projects Scrum Require collaboration Between team members and stakeholders, so That it is
important to have the commitment to All involved.
For this purpose, we recommend:
• Define clear and correct expectations for Everyone involved.
• Communicate in time and with sufficient detail the commitments and importance of the
participation of LYou involved.
• Always keep informed LYou involved About the progress and/or changes that the projects may
have (using simple language that everyone involved can understand).
• Avoid meetings that do not generate value or overextended meetings that significantly disrupt
the activities Of those involved.
• Always communicate the results and benefits achieved with the execution of each project.
• Thank the team involved and officials for their participation and highlight the importance of
their ideas and reviews.
- Possible turnover of staff currently involved in the project

One of the greatest risks to which a project is normally exposed, It is the possible resignation of the
members of the team, so it is recommended:
• To carry out knowledge transfer between Team members.
• constitute a basis for Knowledge and lessons learned.

• ensure continuous documentation.
6.3.2 Appetite for risk
The risk appetite is a model usedOr to measure the preference of interested parties By the risk or their
attitude towards the RIesgo. This defines the level of stakeholders To accept Risks.
Illustration 21 -Appetite for risk
6.3.3 Risk tolerance
Risk tolerance is the maximum amount of risk that The Organization is DISpuesta to accept to achieve the
Objectives of the project; Risk tolerance Serves as an alert to avoid reaching the risk capacity.
Risk capacity
The Ability to Risk is the level of risk Maximum That can be allowed before the project is diverted in such a
way that it does not deliver value to the customer. In case of exceeding the risk capacity, the project is
usually terminated (SectionN - Stage 6: Project shutdown).

6.3.4 - Life cycle of risk management
The management Of risks consists of five Steps Listed below:
Illustration 22 -Life cycle of risk management
6.3.4.1 - Risk identification 1
Risk identification allows you to know the possible risks that may affect the development of the project and
its respective sprints.
There are 2 important moments where risk identification is carried out:
• To iNicio Of pProject: Se IDentifican Risks GLobar del pProject, for example, budget-related risks,
the PErsonal, etc.
• The sprints: Is Identify the RIesgos What May affect the development of That particular Sprint, for
example, RIesgosl pRoduct. This activity is made ITE formRativa throughout the project mainly at
the Sprint planning meetings.
SoLooking at the project from different perspectives and using a variety DAnd techniques, you can identify
the possible risks. The Technical máS used is The LLuvia iDeas.
6.3.4.2 - Evaluation of risk 2
Risk assessment helps to understand the potential impact of a risk, how likely it is to occur, and when is it
possible for the risk to materialize? A decision may be taken and determine If it would be a good idea to
continue Sprint or even the Project.
Risk assessment is done considering 3 factors:
• Proximity = Number of days or estimated date on which Could present The risk.
• probability = Measure Percentage that helps determine the possibility of risk occurring.
• Impact = Measures the damage that causes the risk, is usually classified numerically according to
the following categories: Critical (6), very high (5), High (4), Medium (3), Low (2), very low (1)
Illustration 23 -Criteria for risk assessment
6.3.4.2.1 – Expected monetary value
This technique is used to calculate the impact moneThat you may have a risk, and with this information
make a reservation for the prevention and/or mitigation of risks.
The technique considers 2 factors: the monetary impact of risk and probability of occurrence.
Example: An organization that implements solar energy systems detects a possible tropical storm that
would prevent it from continuing with the installation of the planned panels for the next Sprint. To calculate
the impact that this would have on the project identify factors such as possible penalties, people's salaries,
etc. Coming to the conclusion that for this risk would be lost 538 dollars. The next step is to calculate the
probability of risk occurrence, which according to the Meteorological Institute is 35%. By applying the
technique as explained, the monetary value of that risk is 188.3 dollars.
6.3.4.3 Prioritizing risk 3
Prioritization of risks makes it possible to establish a risk mitigation order. In order to prioritize the risks,
the following steps are carried out:
• Identifiesr The approximate date in the That the risk would be presented. (Consideredr That the
most NGN risksShould be taken care of first).
• Calculatedr The exposure factor (relationship between probability and impact) and with this factor,
prioritizes the closest risks.
6.3.4.4 - Risk mitigation 4
In the mitigation stage, the Scrum team determines the action to take with the risk. In Scrum there are 3
possible responses to the risks:
Illustration 24 -Risk mitigation actions
• The response to each risk will depend on the probability and the impact of the risk.
• The iterative nature of Scrum, with its response time and fast feedback cycles, allows failures to be
detected early; Therefore, speaking in practical terms, it has a natural mitigation function built into
the system.
• Risks can be mitigated by implementing a series of responses that can be proactive/preventive or
reactive.
6.3.4.4.1 Mitigation
• Mitigation focuses on reducing the probability of occurrence or the impact of risk.
• Includes actions taken in advance or proactive actions.
• Risk exposure (probability vs. impact) is reduced within acceptable limits for the project.
6.3.4.4.2 – Contingency
• The contingency focuses on defining a response that is used if the risk materializes or identifies
warning signs.
• Includes reactive actions and monitoring actions in case the risk is inevitable.
6.3.4.5 - Risk communication 5
Stakeholders should be continually informed about theL State of the risks, INcluyendo the potential impact
of these risks and the planIt's to respond to every risk.
Risk communication is usually tookAda out by the Scrum Master towards Product Owner And By the
Product Owner to the customer.
This communication is always in progress and must occur in parallel During The four sequential steps
discussed so far.
6.4 - Management of Changes
Agile implies openness to change, so it is common that all agile projects are exposed to change, and it is
vitally important that team members are prepared to cope with changes at any stage of the project.
It is even more important for the Organization to be aware of exposure to changes in order to create synergy
with Scrum teams and seek to take advantage of the benefits by minimizing the negative impact that could
result from change.

Given the iterative or incremental nature of Scrum, it is possible Handle changes in the product in an orderly
and cyclic way, responding continually to what the customer expects; In correspondence with the Agile
Manifesto, "We accept that the requirements will change, even in late stages of development. Agile processes
leverage change to provide customer competitive advantage ".
Although in Scrum there is a strong inclination to not keep large amounts of information worthless, orThe
appropriate way to request changes to Scrum products is through the request for Change format (RFC),
however, this does not imply that there is necessarily documentation in-between.
A good RFC, you should have At least The following components:
• Who requests the change? Why? Why do we need to do this?

• When is it needed?
• How important is it?
• What happens if the change is not made/approved?

• Who's going to execute it? What do you need? Are you an employee or should we hire?
It is important that behind each requested change there is an "initiator" to keep the trace between change
and know where it comes from. In addition Within the management of changes in Scrum It recognizes the
authority of the product owner in the approval/rejection of the changes, so it is important that throughout
the project, the product owner is aware Of what happens to the product.
The following describes the flow of changes:

Illustration 25 -Flow of changes
• The Product Owner is the responsible role of approving/rejecting changes, however, sometimes
when the changes are out of their knowledge or are out of range defined for the project you will
be able to scale the changes to the management of The Organization.
• The changes can come from different sources, the most common are:
o Changes requested by stakeholders.
o Requests made by team members.
o New technologies Emerge And you need to make changes to the product.
o The defined product begins to lose validity and it is necessary to change the range.
6.5 - Product design
Scrum is commonly used for the management of agile projects oriented to the construction of
products/services, however, pre-project stages such as conception, prototyping and product design do not
They are always explained to the detail, being highly important for the good development of the project.
Some of the concepts that should be considered at this stage are:
6.5.1 - Viable minimum product
Defining the minimum Viable product or also called Minimum market characteristics is An activity Extremely
important, so that the first version of the product It builds up as soon as possible, leading to an increase in
return on investment.
Typically, these requirements would be placed as high priority Within the Product Backlog.
The minimum Viable product is defined between the Cand the Product Owner.
6.5.2 -Analysis of Product viability
The aim of the Lean canvas model (adapted from Business model canvas) is to identify the viability of a
product or service and thus reduce the risk and The Possible obstacles.
On many occasions The Lean Canvas It is used as the artifact Business case replacement.
The keys when building a Lean Canvas are:
• Create: Raise the idea and test with low-cost prototypes.
• Measure: Check The INTErés of potential users and measure Results.

• Learn: With the results Is Decides whether is continued with the Idea or is changed Something.
The Lean Canvas is composed of 9 quadrants, as described below:

Illustration 26 -Lean Canvas
7. The life cycle in agile projects

Scrum was designed as a framework based on simplicity, so we do not use the concept "process" to describe
the Scrum practices that allow the development of a project. The processes as they are known are better
left to traditional methodologies.
A project developed with Scrum Has 6 Stages defined in their life cycle, each stage with a respective set of
practices (17 in total). To Then The life cycle of a Scrum project is displayed.
Illustration 27 -Life cycle in a Scrum project
7.1 - Stage 1: Start of the project
Id Practice Role vs Level of involvement
Stage 1: Start of the project
1 7.1.1 -Define the vision of the project (1) • Product Owner: Alto
• Scrum Master: null
• Development team: null
2 7.1.2 -Form the Scrum team (2) • Product Owner: Alto

• Scrum Master: High
• Development team: N/A
3 7.1.3 -Build the Backlog Product (3) • Product Owner: Alto

• Scrum Master: Middle
• Development team: Middle
4 7.1.4 -Prioritize Backlog (4) • Product Owner: Alto

5 7.1.5 -Define the delivery schedule (5) • Product Owner: Alto

• Development team: High
6 7.1.6 -Define the product architecture (6) • Product Owner: Middle

7.1.1 - Defining the Project Vision 1
In the practice of "defining the vision of the project" The Vision of the project is structured, explaining the
business needs QThe project seeks to satisfy, considering The scope, time, budget and quality expected by
the project sponsor.
Some of the key activities in this practice are:
7.1.1.1 - Project restrictions
Projects always have limitations, also called "Constraints." There are usually 4 main restrictions (time,
budget, scope and quality), however, depending on the nature of the project and/or the style of the
organization, other restrictions may exist.
Illustration 28 -Project Restrictions
7.1.1.2 - Identify stakeholders
At the beginning of the project, the Product Owner is responsible for ensuring that all stakeholders are
identified. To do so, it is recommended that all in turn be registered, in what is commonly called "Matrix of
stakeholders"
This matrix contains the following information:
• Employees who work for the project, their respective role and the time in hours they dedicate to
the project.
• Project Vendors.
• Customers/Users who will be interviewed, review the project or provide useful information for the
construction of the product.
7.1.1.3 - Definition of finished DoD
When an element Product Backlog Or Of Increase is described as ' finished ', everyone should
understand Which means "terminated" (Done); Although this Can vary significantly for each Scrum
Team.
LTeam members must have a shared understanding of what it means that the job is completed to
ensure transparency. This is the definition of "done" for the Scrum Team, and is used to evaluate when
the work on product increment has been completed.

This same definition guides the Development team In knowing how many elements Product Backlog
You can select during the Sprint Planning. The purpose of each Sprint is to deliver increments of
functionality that can potentially be putEr in production and that fitsN to The definition of "terminated"
(Done) Current Scrum Team.
Development team delivers an increase in product functionality in each Sprint. This increase is usable,
so The Product Owner I could choose to release it immediately. If the definition of "done" for an
increment is part of the conventions, standards or guides of the development Organization, at least all
scrum teams must follow it. If "Done" for an increment is not an organization convention, the
Development team Of Scrum Team You must specify an appropriate "done" definition for the product.
If there are multiple scrum teams working on the delivery of the system or product, the teams of
developers in all scrum teams must define in conjunctionTo the definition of "terminated" (Done).
Each increment is integrated with all previous increments and is thoroughly tested, ensuring that all
InCrementos work together.
As Scrum teams mature, their definition of "done" is expected to Is Expand to include more rigorous
criteria for an MAYor quality. The use of the newS Criteria Can discover work to be done in the
IncremeHow many underground previously "terminated" (Done). Any product or system should have a
"finished" definition (done) that is a standard for any work done on it.
The definition of terminated can be defined for:
• One Sprint.
• A set of sprints.
• A project.
• A program.
• The entire organization.
A generic example of completion criteria can be:
• The elements were reviewed by other team members (peer testing was done).
• All defects are fixed.

• User History Unit tests completed.
• All technical and end user documentation was completed.
• All files and documents in the project are in the organization's repository.
• The successful demonstration was made to the partners and/or representatives of the company.
• The customer gave his approval to the deliverable.
7.1.2 - Form The Scrum Team 2
During this practice we choose the members who will be part of the different Scrum teams.
7.1.2.1 - Collaboration Plan
This artifact defines how different stakeholders and project team members participate, communicate and
collaborate throughout the project. You can also define the specific tools or techniques that will be used
for this purpose.
For example, when and how meetings will be conducted, what kind of communication tools will be usedn,
and who should be involved in the various meetings.
In large and complex projects, especially with distributed equipment, This Artifact has much more formality.
In other small projects, sometimes it can be just a verbal understanding.
It is usually an artifact that is built in a brief meeting (30 Minutes maximum), and the opinion of the whole
team is considered.
7.1.2.2 - Meeting of Project start o Kickoff
In this meeting the people responsible for executing the project and the client participate to formalize the
new project and at what point it starts. This meeting is also a tool that facilitates communication in The
Project. (This meeting is directed by Product Owner).
The Main goals of the kick meetingFF are:
• Present the objectives, beNeficios and scope of the project.

• Present the project team.
• Get the commitment Of the team and stakeholders In front of the project.
• Present the initial work plan.
• Present The Initial risk identification.
• Define communication during the project.
7.1.2.3 - Team Development model – Dr. Bruce Tuckman
Dr. Bruce Tuckman defined the model To describe the Course That most teams are still on their way
to high performance.
Illustration 29 - Team Development model – Dr. Bruce Tuckman
• 1. Training (Address)
This is the stage in which the team is formed and the team members are beginning to know each
other, so initially their behavior tends to be individualistic. During this training phase the first
interactions between them are established, so it is common that no conflicts or arguments are
presented.
This stage also defines the rules of the team, its purpose and identity (a name for the team), which is
part of a good working environment for the team.
At this stage the Scrum Master takes a pos"Director" decision since the members of the Team
dependsn Of it for the definition of the course of the team and its orientation.
• 2. Confrontation/conflict
In this phase confidence has already been generated among the team members, so there are differences in
the team and the members compete with each other, establishing or breaking relationships between them.
Since each member has its own personality and working style, it will be necessary to reach a coexistence
agreement to avoid a decrease in motivation.
Although the phase alludes to the confrontation, it is also necessary that these clashes be resolved to ensure
good performance of the team.
In this phase the Scrum Master takes a position of "coach", providing accompaniment to the team and
guiding the members to keep the conflicts under control. You should also remain calm and give an example
of the desired behavior for the other team members to emulate and adopt healthily. The Scrum Master is
also responsible for promoting activities that increase the motivation of the team and identify the
interactions that improve or impair the coexistence in the team.

• 3. Standardization
In this phase, conflicts are reduced and agreements are generated that improve interactions between team
members. During this phase, members understand better what their responsibilities, strengths and
weaknesses are, which leads to an environment of greater trust and collaboration.
Each member is already aware of their place in the team and is able to understand and accept the work
style of the other members, so personal interests move to the background to prioritize the interests of the
team as a whole.
In this phase the Scrum Master is a "facilitator", since it takes a focus towards the improvement and
conditioning of the environment to facilitate the performance of the team. Because in this phase the Scrum
Master knows more about the team, it can identify how its members better fit and how it can increase their
performance and motivation.
It is common that in this phase they can incorporate new members to the team, so the Scrum Master has
to ensure to maintain the stability of the team ensuring that the new members are easily integrated into
the team without diminishing their performance or their motivation.
• 4. Performance
In this phase there is a mature team with sufficient confidence, motivation and autonomy so members are
able to make certain decisions without the presence of a "boss", and can delegate tasks that were previously
exclusive to the Scrum Master (as Conduct daily meetings, identify impediments, Etc.). In addition, team
members are already able to resolve disagreements or differences positively and in a short time.
It should be recognized that not all teams arrive at this stage as it is achieved after Of Confront conflicts
and great difficulties, coexist and share experiences, implying that many teams do not fully achieve the
stage of normalization and remain stagnant in the stage of confrontation.
This stage does not require much effort by the Scrum Master, allowing you to focus much more on
maintaining and improving the work environment of the team favoring the high performance of the
members.
• 5. Termination/Dissolution
This stage comprises two situations: the dissolution of the equipment or the completion of the equipment.
The dissolution occurs when eventually during the project, one or more members leave the team, which
causes a delay in the progress that had already been achieved, leading to a decrease in motivation and
performance, because the team is resentful after the Loss of stability.
The finalization of the team is presented when the project is finished and the team members become part
of another project or another company, which implies that, although the objective of the project has been
successfully achieved, the members generate a sense of " Loss "as the interactions already established and
already working properly will be terminated along with the project. In some cases the same team can be
part of a next project, however, as a new project does not necessarily mean that the interactions
pErmanecerán in the same way.
It is necessary for the Scrum Master to provide accompaniment to the team, because whether it is
dissolution or completion, represents a significant change for team members.
7.1.2.4 - High Performance equipment
A high Performance team is one that has a performance nothigher than the average. EN Scrum normally
The performance It is associated with the speed with which the team manages to deliver value. For logRAR
High Performance equipment, it is necessary to consider at least the following factors:
• should be measured Performance continually.
• Should uUse tools to automate As many tasks as possible.

• The vision and rules must be clear from the beginning of the project.
• It is essential to ensure the presence of That encourage creativity.

• The Objectives Defined must be a challenge for the team.
• The equipment must Stay Motivated.
7.1.3 - Build the Product Backlog 3
During this practice the Product Backlog is built (See section 4.1- Product Backlog).
The elements that makesn Part of the Product Backlog are:

• Epic.
• User Stories.
• Errors.
• Tasks.
• Proof of concept.
Some of the most relevant features are:
• Its elements andIsn Ordereds According to the priority.
• Its content is directly related to what was agreed with the project sponsor.
• Each element that makes partE product Backlog is called PBI (product Backlog Item).
7.1.3.1 - Classifying the Product Backlog
During the construction of the Product Backlog It is important to classify the elements of the Product
Backlog, for which you could use the concept of "epic".
The epics Allow Groupsr The Product Backlog Elements, allowing better navigation by himself. Some ideas
that could be defined as epics are:
• Modules.
• Components.
• Milestones.
• Deliverables.
• Functionality.
7.1.4 - Prioritize Backlog 4
Prioritizing the elements of the Product Backlog is a key practice to guarantee LA customer value delivery.
Toome of the factors that must be considered for the prioritization of user stories within the Product Backlog
are:
• Time.
• Effort.
• Functional value.
• Dependencies.
• Risks.
• Opinion of the stakeholders.

• Opinion of the development team.
• Market value ($).
Note: The priority of Items can change during project execution.
7.1.4.1 – Urgency Prioritization
One of the prioritization techniques Product Backlog is determined by the urgency and value they represent
The elements of the Product Backlog pInterested parties.
The elements that contribute more value to the business and have a greater urgency will have a higher
priority in the Product Backlog:
Illustration 30 -Urgency prioritization
7.1.4.2 - Visual Story Mapping
This is a technique to provide a visual outline of the product and its key components. The Visual Story
Mapping, Was Formulatedo by Jeff Patton in 2005, And It is commonly used to illustrate the trajectory of
the product.
This represents The sequence of product development iterations (from left to right the components are
organized according to their priority of developmentOr, as shown in the picture):
Illustration 31 -Component planning or Visual Story Mapping
7.1.5 - Define the cRonograma of deliveries 5
In this practice, the Product Owner in the company of the other members of the EEquipment Scrum, define
the high-level project schedule.
In this practice, the duration of the Estimated of the different sprints (since We already have the elements
of the Product Backlog prioritized).
This schedule includes the description of high level Of the activities, commitments, tasks specifically
assigned to the members of the development team, which will be Refining Throughout the project, in
meetings Dand planning for each sprint.
Illustration 32 -High level calendar in a project
Note: This schedule will be updated in an iterative way During The Sprints.
7.1.5.1-Team Calendar
The Team Calendar It contains information about the availability of the team members, considering the
information pertaining to:
• The holidays of the Members of the Scrum team.
• License Dates.
• Important events in the organization.

• Holidays.
• Office events.
• Ongoing projects.
• Etc.
7.1.6 - DEfinir The Architecture of product 6
The objective of this practice is toStablecer or refine The technical design of the product or the
compoComponent of product to be developed. Although this activity is always obligatory at the beginning
of the project, it could also be done iteratively before developing components in the different sprints.
To ensure that the product architecture that is defined meets exactly the customer's requirements, it must
be done jointly between the development team and the product Owner.
Before starting the construction of the product it is important to identify the relationship between all the
components that will be part of it.
Example: A software development company plans to build an application to perform virtual courses.
Being a software project, The following elements must be taken into account in the definition of
architecture:
• Data Bases.
• Storage servers.
• Processing servers.
• Domain names.
• Email processing servers.

• Firewall.
• WEB Services.
• among others.
7.1.6.1- SPrint Zero
This iteration is the first to be performed. The goal of Sprint Zero is to prepare the project team from a
technological, methodological and organisational perspective, looking to form a team and not just a group
of people.
This activity analyzes and evaluates the possible solutions that can be established for the development of
the project.
These possible solutions can be:
• Tools.
• Technological solutions.
• Technical solutions.
For each solution chosen is You must carry out a proof of concept, where the following criteria must be
taken into account:
• Learning curve.
• Scalability (only if technical or technological solution).

• Support.
• Cost.
Note: This sprint is only used for those cases where the project team has little or no experience in the
technology in which it is going to Build the Product Or even if you have little or no experience in the type
of product that is going to develop.
7.1.6.2- Supplier evaluation and selection
The purpose of this activity is to guarantee the objective selection of the suppliers, using the criteria defined
by the organization. (See more information in the section - Hiring of suppliers).
7.2 - Stage 2: Planning
Stage 2: Planning
7 7.2.1-Write User stories and tasks (7) • Product Owner: Alto

8 7.2.2 -Prioritize User Stories (8) • Product Owner: Alto

9 7.2.3 -Sprint Planning Meeting (9) • Product Owner: Alto

7.2.1 Writing User Stories and tasks 7
7.2.1.1 What are the User Stories?
User stories are a more understandable and accurate way to write the requirements to be developed in the
project.
They are composed of 3 elements mainly:
• As: Describes the role of the person or group That requests (or would use) the functionality o
Requirement.
• I want to: Describes the need or requirement of the user, Usually, it's a short sentence.
• For: Describes the benefit expected by the User Once the requirement is developed.
Bill Wake invented the acronym INVEST to describe the characteristics of a good user story:
• Independent: Stories can be completed in any order.

• Negotiable: The details of the story are co-created by developers and customers during
development.
• Valuable: Functionality is valuable to customers or product users.
• Estimable: Developers can find a reasonable estimate to build the story.
• Small Small: Stories should be built in a short time, usually around "days/person." You have to be
able to build a lot of stories in an iteration.
• Likely (testable): You should be able to write evidence that verifies that the product of the story
works properly.
7.2.12 Mockups and ProToInitial project Types
The Mockups represent the DLayout of the product before its development, consider the Flow That should
follow the product, and serve to show the possible functionalities to the client and thus confirm that these
will deliver the expected value.
The mockups are usually a set of sketches, designs, Diagrams and/or representations; And it is especially
necessary to have a pre-Sprint mockup or prototype, as these will serve as a guide for team members.
Illustration 33 – Mockups
7.2.13 Parallel planning
One activity that can make a big difference is parallel planning. This activity consists in forming a small team
of people who are in charge of carrying out the planning activities in parallel with the development of the
realized elements. This will make Sprint's planning meetings much more efficient. Some of the things that
can be done Parallel to the development Are:
• Conduct the interviews or research necessary to write the user stories.

• Make the prototypes and confirm the value with the user.
7.2.1.4- Breakdown user Stories into tasks
This Activity serves to Identify the possible dependencies between the user stories, to do this, a list is made
with all the tasks that should beEvar out to complete the user story.
Usually four types of dependencies are differentiated Between user Stories:
• Mandatory dependencies.
• Discretionary dependencies.
• External dependencies.
• Internal dependencies.
Some techniques that can be used for DGlossing User Stories in Tasks Are:
• Flow charts.
• The Gantt charts.
7.2.2 - Prioritize the User Stories 8
This practice is related to the parallel planning, because while the team finishes developing the established
for the last Sprint, the Product Owner performs aA prioritization of The User Stories That can be considered
for the next Sprint and that can be taken as a basis for guiding the team's course.
It is important that this prioritization be done before the Sprint planning meeting is carried out in order to
optimize the time.
The elements to be considered for prioritizing user stories are:
• Business value.
• Risk.
• Dependence.
7.2.3 - Sprint Planning Meeting (9)
7.2.3.1 - Select the job to develop
The product Owner exposes the goal that the sprint should achieve and the elements of the product Backlog
that, if completed in the sprint, would achieve the goal of the sprint, with this the development team works
to project the functionality that will be developed during the Sprint.
The entrance to this meeting isTituida by the product Backlog and taking the prioritization of user stories
made by the product Owner, including also:
• El Last iProduct Ncremento.
• LA projected equipment capacity Development for the Sprint.

• The speed of the Development team.
• Failures found to the product or product increments (error log).
The number of items in the Product Backlog selected for Sprint depends solely on the development team.
Only the development team can assess what they are able to accomplish during the Sprint that begins.
During the sprint planning the Scrum team defines the goal of the sprint. The goal of the sprint should be
achieved during the sprint through the implementation of the Product Backlog and provides a guide to the
development team of why the increase is being built.
7.2.3.2-Estimation of the selected work
It's very importantYou to estimate the selected work (commonly written in the form of User Stories) To be
able to make more accurate planning.
To ensure a more accurate estimate, criteria should be considered:
• Size.
• Complexity.
• Duration.
• Amount of resources.
• Risks.
• Limitations.
Normally the estimation techniques used by Scrum are based on expert judgement, however there are other
techniques that can be used and combined:
Planning Poker
The planning poker consists of a set of numerical cards that serve to perform the estimation of tasks or user
stories.
• Poker can be numbered from 1 to 10 or by using the Fibonacci sequence.
• The use of poker pRomueve more interaction and better communication between participants, as
well as making the Sprint planning meeting more dynamic.
Fist of Five
It is a technique that allows Achieve consensus in Scrum teams. It is done using the fingers of the hand,
where EL number of fingers used for voting indicates the level of agreement and the desire for discussion:
• A finger: I disagree with the group's conclusion and have great concerns.
• Two fingers: I disagree with the conclusion of the group and I would like to talk about some
Problems Minor.
• Three fingers: I am not sure and I would like to assume the consensus conclusion of the group.
• Four fingers: I agree with the group's conclusion, But I would like to discuss some Problems Minor.
• Five fingers: I totally agree with the group's conclusion.
7.2.3.3-Team Commitment
One of the key activities during the planning of a Sprint is theOwn of The User Stories and tasks on the part
of the development team, this is accomplished when team members are CarThey assign the work to
develop, in turn they acquire the commitment Public To finish the job.
It is extremely important to ensure that there is balance in the amount of work selected by each team
member.
It usually happens that in teams Scrum where they are combined Expert members and Novice members
There will be an "imbalance" in early stages of the project, as the expert members have more work capacity
while the novice members are leveled in their learning curve.
7.2.3.4 -How will you get Finish The selected work?
Once the target has been set and product Backlog items have been selected for the sprint, the development
team decides how it will build this functionality to form a "finished" product increment during the sprint.
The elements of the Product Backlog selected for this Sprint, Along with The plan to finish them, gets the
name of Sprint Backlog.
DThe Sprint planning You must ensure that is planned The Enough work so that the development team can
do a projection of what they think they can complete in the starting Sprint.
By the end of this meeting, the work planned by the development team for the first days of the Sprint is
decomposed into units of a day or less. The development team organizes itself to assume the work of the
sprint Backlog, both during the sprint planning and throughout the sprint.
Product Owner can help clarify selected product Backlog elements and make concessions. If the
development team determines that you have too much work or do not have enough work, you could
renegotiate the selected Product Backlog items by the Product Owner. The development team may also
invite other people to attend to provide technical or domain-related advice.
7.2.3.4.1 - Goal of the Sprint
The goal of the Sprint is a goal That is set for each Sprint During the Sprint planning meeting. This goal
describes the scope of each Sprint in alignment with the Product Backlog, in turn pn Outstanding a guide
to the development team about why the increase is being built.
Define the Goal of the Sprint gives the development team some flexibility with respect to the workAlity That
has to be built In the Sprint.
• LOS elements Selected Product Backlog offer a Guidance on what That may be the goal of the
Sprint.
• The aim of the Sprint Guarantees That the development team work together rather than on separate
initiatives.
• Usually the goal of the sprint is usually a short phrase that simply explains the expected increase at
the end of the sprint.
As the development team works, it keeps the goal of the Sprint in mind. If the work Turns out to be different
from what Hold onDo, Team members scale the situation with the Scrum Master to contactL Product Owner
and can be negotiated The scope of the Sprint.
7.2.3.4.2 - Spikes
A SPike serves to include in a sprint tasks that do not imply to develop a user history and therefore do not
contribute directly To Increase Of Product being developed.
Some examples of spikes are:
• Team Training.
• Project and/or product documentation (eExample: Document source code).
• Deployments/implementations.
• Adoption of new tools.
7.3 - Stage 3: Sprint Development
Stage 3: Sprint Development
10 7.3.1-Develop deliverables (10) • Product Owner: Under

11 7.3.2 -Daily Scrum (11) • Product Owner: Null

7.3.1 Develop the Deliverables 10
The objective of this activity is the development of the Sprint deliverables, the manuals or related
documentation always considering the definition of "terminated".
Note: In conjunction with This Practice, the daily scrums are executed, and the proofs of the deliverables.
7.3.1.1 – The development cycle for software projects
For the development of software projects, usually follows the flow shown in the chart below:
Illustration 34 -Life cycle of Software project development
7.3.1.1.1 – The Tests
Tests are a way to check the correct functioning of the product. There are usually several types of testss,
being the main ones:
• Unit tests: Son EscritAs by the same developer following The criteria of User history acceptance.
These tests SUelen be done in an automated manner.

• Peer Testing: They are usually manual, In which the colleague revises No SoThe performance, but
the quality of the code, and compares the result VS prototypes.

• Integration tests: are usually automated. These are Run on each integration and before each
delivery.
Two types of test execution are also distinguished:
• Manual Testing.
• Automated testing.
The 2 possible outputs of a test are:
• Approved: Meets all expectations and/or acceptance criteria of user Stories that are being tested.
• Rejected: NO compliance with all expectations and/or acceptance criteria Of the user stories that
are being tested. When a user story is rejected during testing, sE Must Reportsr The error in an
"error Log"Normally Within the Product Backlog.
Error Reporting
It is important to note that errors must go through an estimation process equal That user stories (sand
plans its resolution in the Different SprintS of the Project).
When errors are reported, consider:
• Avoid writing vague statements or unproven assumptions.

• Put tGeneric Ítulos to errors.
• Errors should be categorized, eg: errors in production, errors of colleagues, errors in the revision,
etc.
• should be described as PAsos Simple and repeatable playback For what The person who Correct
the error You can follow the sequence.
7.3.1.1.2 – Continuous Integration
Continuous integration is a software development practice whereby developers combine code changes in
a central repository periodically, after which versions are executed and Tests toUtomáticas To ensure the
integrity of the code.
To facilitate continuous integration:
• It should be Have a unique repository for the code Source.

• should be GArantizar That the code is constantly updated both in the repository and in the work
environment of each developer.
• Always Runr Automated testing to ensure that when code is mixed, features are not lost or
damaged Existing.
7.3.1.1.3 – Documentation
The documentation is a vital aspect in the software projects, this will allow the subsequent understanding
of the source code and thus guarantee the collective ownership of the product. For documentation to be
effective, ensure that:
• Sea FEasy to write and understand.
• Must be COmpartida with everyone.
• is updated daily.
• Must have an index or Search.
• Must be ORRganizada by modules or components.
• Must be toA commenta All over the team.
7.3.1.1.4 – Refactoring
The goal of this technique is to improve the maintenance of existing code and make it simpler, more concise
and more flexible. Refactoring means improving the design of the current code, without changing the code
behavior. ToOme of the advantages of the refactoring are:
• Improve the ease of understanding of the Code.
• Improve Its structure and design.
• Delete Dead Code.
• Facilitate future maintenance.
Some of the key moments to perform the refactoring are:
• After passing an automated test.
• When adding a new feature is Quite complicated.

• When it improves The Knowledge Or Experience of the development team.
• When The team Dedicated Quite a while To understand the detail ofl Code.
Some examples of refactoring are:

• Organizing the document/file repository.
• Separation of functions.
• Renaming variables.
• Simplify interfaces.
7.3.2 - Scrum Diario 11
For more details see the Section 3.3- Daily Scrum (daily scrum)
7.3.2.1 SPRINT Progress Tracking
At any time during a Sprint it is possible to Know the progress of Sprint adding The total remaining work
on the elements Sprint Backlog. The Development team Keeps track of this total remaining work At least in
every daily Scrum To project the possibility of achieving the objective of the Sprint. Keeping track of the
remaining work throughout the Sprint the Development team You can manage your progress.
7.4 - Stage 4: Sprint review
Stage 4: Sprint review
12 7.4.1-Sprint Review Meeting (12) • Product Owner: Alto

13 7.4.2 -Sprint Retrospective Meeting (13) • Product Owner: Null

7.4.1 Sprint Review Meeting 12
This review meeting demonstrates the product Owner's increase and Invited stakeholders, in order to get
approval about what was expected and what was developed by the team.
To Then The activities that are performed during the Sprint review meeting are listed:
• Submit Product Increment: The development team presents the product Owner and the Scrum
Master with the increase of the products developed.
• Test product increment (validation): The Product Owner and the invited stakeholders (soIf any)
prove the product increase based on the comparison of development versus each user story and
acceptance criteria. (It is valid to have a checklist to keep track of what is fulfilled and what is not
fulfilled.)
• Product Increment Approval: Based on the increase presented and the validation The product
Owner gives the approval of the increase of products. If the increase does not meet the expected
increase can be refused.
• monitoring, control and monitoring of the project: See more in Section 6.2 - Monitoring and
control Ofl Project.
• Team Pace/Speed: The pace/speed of the development team is identified.
• Team commitments: Team commitments are identified in case of rejection of product increment
Or point-in-time user stories.
o In case of rejection, improvements are added to the Product Backlog with the highest
possible priority, in order to correct them in the next sprint if possible.

• Update Product Backlog: You must update the Product Backlog and terminate the current sprint.
CóMo are validations performed?
This meeting presents the increase of the product to the stakeholders, which will ensure that each of the
features Established and requested in the Sprint Are Completed (under the guidelines of acceptance criteria
And the "Finished" criteria).
7.4.1.1- Technical debt
Technical Debt Sand refers to the work that Teams skip or not complete during one or more sprints.
• If the technical debt accumulates, you canTo carry out maintenance, Integration and high costs in
product deployment.
• Frequent prioritization of user stories contributes to lower technical debt.
• Any technical debt should not be taken beyond a sprint.
Some of the causes of the technical debt are:
• Inadequate or incomplete assessment of user stories
• FCoordination among team members

• Poor exchange of business knowledge
7.4.1.2- Refinement of the Product Backlog
The refinement of the Product Backlog is the act of adding detail, estimates and order to the elements of
the Product Backlog; This is a continuous activity In The Which one The Product Owner and the development
team examine, review and detail the elements of the Product Backlog.
• LItems of the product Backlog can be updated at any time by the product Owner or at your
discretion.
• Refinement usually consumes no more than 10% of the time of the Sprint review meeting.
7.4.2 - Meeting of Sprint Retrospective 13
The sprint retrospective is an opportunity for the Scrum team to inspect themselves and create a plan for
improvements that will be addressed during the next sprint. The retrospective should be done in a liberating
environment that allows the team to flow all kinds of ideas.
The sprint retrospective takes place after the sprint review and before the next sprint planning. This is a
restrictive meeting Maximum of 4 Hours for one-month sprints.
The Scrum Master teaches everyone to keep The positive and productive event; And Participates of this
Meeting as a member of the team as they Part of The responsibility of the increments It falls on him.
The Scrum Master motivates the team to improve Their development process and their practices to make
them more effective and enjoyable for the next Sprint. During each Sprint retrospective the Scrum team
Identifies and Plans ways to improve product quality by improving quality De practices, which can be
implemented in the next Sprint.
Implementing these improvements in the next Sprint constitutes the subsequent adaptation to the
InspeDevelopment team Suction Same. Although improvements can be implemented at any momentOr,
the Sprint retrospective It offers a dedicated event for this purpose, focused on Inspection and adaptation.
In short, During the retrospective:
• The task force focuses on answering the following questions:

o What things have worked well.
o CUá CaveThey have to be improved.

o What things you want to try The team In the next iteration.
o What the team has learned.
• Team identifies actionable enhancements to maintain or improve team work, and maintain the
motivation of the members.
• The team documents and updates the lessons learned record.
7.5 - Stage 5: implementation
Stage 5: implementation
14 7.5.1-Implementation Planning (14) • Product Owner: Middle

• Scrum Master: Under
15 7.5.2 -Implementation of deliverables (15) • Product Owner: Middle

The objective of this stage is the PResponding in production of its Increments Approveds in the REvisión of
the SPrint, for immediate use and utilization by the customer and/or interested. In Scrum projects, it is
usually an iterative stage, in order to take advantage of all the increments usable from early stages of the
project.
According to the nature of The organization, it is commonTRácticas be executeds by groups other than the
Scrum team, however it is highly recommended that it be the same team that is responsible for this work,
thus ensuring a real commitment to the quality of the deliverables, while avoiding the emergence of a
culture of guilt.
7.5.1 Planning the implementation 14
The objective of this practice is to prepare all the necessary elements to carry out a successful
implementation of the increments generated in the sprints, significantly reducing the risks that may
negatively impact the operations of the Users/Customers.
The amount of deliveries (deployments) will depend on the agreement with the client or sponsor of the
project, and usually depend on the value for the organization.

7.5.1.1- Coordination with operations
A key activity is coordination with the different customer operations teams to prepare for the
implementation.
Some key elements in this activity are:
• When will the implementation be implemented?

• Which users will receive the new product?
• Will the product implementation affect operations?
• How Will be notified to users?

• Are users trained to use the new product?
• What will the development team do if the implementation fails?
Note: It is highly recommended that the operations teams have participated in the Sprint review meetings.
7.5.2 - Implementation of deliverables 15
This practice seeks to make available to users The completed and usable increments Previously Developed
by the Scrum team.
It should be clarified that this practice is not possible to apply in all types of projects, nor is it mandatory to
execute it at the end of each Sprint, soIt will be applicable when The product increase Generate value for
the users or for the organization.
The implementation of deliverables can be done in several ways, the 2 most common are:
• Big Bang: This type of implementation seeks to make the increase available to the entire user
community at the same time. It is also called "massive implementation."

• by phases: This type of implementation is used ton case you want to do a segmentation of the
Users CoupleTo implement The increase (ex: Deliver only to Users Specific).
7.5.2.1 - Successful Deployment Confirmation
Once the product increase is in productive environments, it is important to confirm that there were no
affections to the operation, so you could run reviews or post-implementation tests.
On many occasions after successful implementation confirmation, formal notification is made to the
customer (including sE Signature Some artifact As constancyAnd thus reduce the likelihood of new requests
for changes to arise About the elements already delivered.
7.5.2.2-unsuccessful deployments
In case the results of implementation Are negative will be assessed quickly sI can be solved during aA
Maintenance window, otherwise you should make a “Rollback” and plan a new Sprint In which they are
solved The problems encountered, giving way to a new deployment.
7.6- Stage 6: Project shutdown
Stage 6: Closing of the project
16 7.6.1 -Project closing (16) • Product Owner: Alto

• Development team: Under
17 7.6.2 Project Retrospective Meeting 17 • Product Owner: Alto

7.6.1 - CLosure of the project 16
At the closing meeting of the project, the closing and reason for the closing of the project will be recorded,
for this purpose it could be built A project closing act.
The following may be grounds for closing the project:
• Successful closure of the project: It was fulfilled with all the deliverables scheduled within the
allocated budget and according to the acceptance criteria (total customer satisfaction).
• Partial project shutdown or postponement: It was partially fulfilled with the scheduled
deliverables, the allocated budget is being exceeded or not fully fulfilled with all the acceptance
criteria (partial satisfaction of the client).
• Project Cancellation: It was not fulfilled with any of the deliverable scheduled, the allocated budget
was exhausted ahead of time, it was not fulfilled with any criterion of acceptance (total
dissatisfaction of the client).
What to do during this stage?
• Deliver the finished product.
• Get approval of the Deliverables of the project on behalf of the client.

• Formally close the project.
• Verify customer satisfaction and stakeholders.
What It takes For the meeting?
• Product or product increase developed by the team: To register the status of the product at the
time of the project shutdown.
• Project Start Act: To validate the scope, objectives and initial aspects of the project.
• Integration Test Results: It includes a report of the tests that were carried out after the delivery of
each increment of the product to ensure the correct integration between components.
• Product Acceptance Criteria: For verification and validation of expectations compared to what
was delivered.
• Customer Documentation/Training: To ensure that the customer has the knowledge about the
use, installation, configuration or basic support of the product.
• Project reports: That show the current state of the project Progress (reports will be displayed as:
Cumulative flow chart and budget diagram).
It is important to have an artifact as evidence of the closure of the project, thus guaranteeing the official
termination of the project activities, or the fulfillment of the subsequent commitments (if any).
7.6.2 - Project Retrospective Meeting 17
Within the objectives of this practice we find:
• Analyze and learn from the successes and errors that were committed throughout the project.
• Analyze the reports generated by quality assurance throughout the project.
• Create a report of improvements and lessons learned throughout the project.
Who participates in the meeting?
• Scrum Master.
• Product Owner.
• Development team.
• Sometimes the customer could even participate.
8 Scrum in big projects

Scrum is designed to work on projects of any size, so What Making some adjustments To what was
explained in the previous sections, It can be used in large projects.
8.1 -Equipment Distribution
When a project is very large and a single Scrum team is not enough to develop all the work, it will be
necessary to have multiple teams. Some of the considerations that should be To take into account for the
distribution of the equipment are:
• As far as possible, you should have a single Product Owner For the project.
• The size of the equipment should be kept balanced.
• Specialized teams should not be formed, multifunctional teams advance faster and generate fewer
dependencies.
• Team members should not be changed during project execution.
8.1.1 – Program Owner
When projects are part of a program, the role of program Owner takes a lot of relevance. The Program
Owner will be the responsible role of:
• Manage the Product Backlog of the program.

• Guarantee the delivery of benefits.
• Approve or reject program-level changes.
• Coordinate the work with the different Product Owner of each project pertaining to the program.
Some roles that could also participate in large projects are:
• Agile Coach: It guides the agile transformation in the organizations.

• Line Manager: Know the line of business to which the program or project belongs.
8.2 - Product Backlog On multiple computers
Often, several Scrum teams work together to develop the Same product. To describe the work to be done
on the product is used A single Product Backlog.
• Could be used An attribute of the Product Backlog to group the elements That belong to the
different teams.
8.3 - Scrum of scrums
Scrum Scrum is The Event focused on the coordination of sprints for multiple teams within the same project.
• This event usually lasts 15 minutes.
• In some projects where the need for communication between teams is vital (eg: when there are
dependencies), it is done daily.
• It should be done at least 1 time per Sprint.

• It is run by a Scrum Master.
• The representatives of each team belonging to the project participate.
Illustration 35 -Scrum of scrums
Meeting Objectives
• Coordinate the work of multiple teams working for the same project.
• Avoid delays due to unidentified dependencies or risks in time.
To ensure effectiveness in this event, the following questions are made:
• What have you been working on tOr team?
• What are you going to work TOr team?
• Have you had any impediments?
• Are there dependencies between your team and other teams?
8.4 - Coordination of Sprints
When you have multiple teams in a project, it is important to ensure that your sprints remain coordinated
over time, that is to say, all teams start and finish their sprints on the same dates.
Illustration 36 -Coordination of sprints
Some considerations to consider are:
• A single Sprint planning meeting should be held.
• A single Sprint review meeting could be made.
• Each team must make their own retrospective. However, it is important to make a regular session
of lessons learned from all teams to share the knowledge acquired on each team.
8.5 – Guidelines on Scrum practices
When Scrum practices and tools are to be adopted in an organization, these do not always conform 100%
to the context of the project, the type of organization or even the specific needs of a specific client, which
is why in different Organizations the APMO designs a set of guides that allow to adapt the Scrum practices
to the context of each project, these guides are called "Adjustment guides".
• The adjustment guides are useful for the members of the different Scrum teams, mainly for the
different Product Owner.

• The adjustment guides can also be used to adapt the audit program by the organization's quality
groups.
9 Thanks
Of the thousands of people who have contributed to Scrum, distinguishedMos To those who provided the
basis for the construction of this book: Jeff Sutherland working with JeFF McKenna and John Scumniotales;
And Ken schwaber working with Mike Smith and Chris Martin – based on "The Scrum Guide”.
We also extend the thanks to the work team of CertMind who during the last months contributed their
knowledge and experience, making possible the set of improvements made to the framework of work, as
well as the community of experts that participated in the editing, tuning and translation.
10 Official terms in English

• Quality Assurance: Quality Assurance
• Daily Scrum: Daily Scrum
• Definition of finished: Definition of "Done" (DoD)

• Cumulative Flow Diagram: Cumulative Flow Diagram
• Development team: Development Team
• Scrum Team: Scrum Team
• Increase: Increment
• Objective Sprint: Sprint Goal
• Limited time periods: Time-Boxes
• Refinement: Refinement
• Sprint Planning Meeting: Sprint Planning Meeting
• Sprint review: Sprint Review
• Sprint Retrospective: Sprint Retrospective

• Daily Scrum: Daily Scrum
• Change Request: Request For Change
• Research tasks: Research Tasks

10.List of figures
Illustration 1-Structure of the guide .......................................................................................................................................... 11
Illustration 2-Agile methodologies vs cascade methodologies ...................................................................................... 12
Illustration 3-The Scrum team ...................................................................................................................................................... 13
Illustration 4-Product Owner ........................................................................................................................................................ 14
Illustration 5-The development team ........................................................................................................................................ 15
Illustration 6-The Scrum Master .................................................................................................................................................. 16
Illustration 7-The Scrum Master guide to the team ............................................................................................................ 17
Illustration 8-The Sprint .................................................................................................................................................................. 20
Illustration 9-Scrum Board ............................................................................................................................................................. 27
Illustration 10- Burndown Sprint Chart ..................................................................................................................................... 28
Figure 11-Cumulative flow chart ................................................................................................................................................. 29
Illustration 12-The client participates in the Agile project ................................................................................................ 34
Illustration 13-balance between bureaucracy and anarchy: agility ............................................................................... 38
Illustration 14-Scrum Team Skills ................................................................................................................................................ 42
Illustration 15 – Competency matrix .......................................................................................................................................... 43
Illustration 16-Equipment needs ................................................................................................................................................. 43
Illustration 17-formula for the calculation of the ROI ........................................................................................................ 46
Illustration 18-Freelancers ............................................................................................................................................................. 48
Illustration 19-Activities of the APMO ...................................................................................................................................... 49

Illustration 20-Speed Scrum Team ............................................................................................................................................. 50
Illustration 21-Appetite for risk.................................................................................................................................................... 54
Illustration 22-life cycle of risk management ......................................................................................................................... 55
Illustration 23-Criteria for risk assessment .............................................................................................................................. 56
Illustration 24-Risk mitigation actions ...................................................................................................................................... 57
Illustration 25-Change flow ........................................................................................................................................................... 60
Illustration 26-Lean Canvas ........................................................................................................................................................... 62
Illustration 27-life cycle in a Scrum project ............................................................................................................................. 63
Illustration 28-Project restrictions ............................................................................................................................................... 65
Illustration 29-Equipment development model-Dr. Bruce Tuckman ............................................................................ 68
Illustration 30-Urgency prioritization ........................................................................................................................................ 73
Illustration 31-component planning or Visual Story Mapping ....................................................................................... 74
Illustration 32-high-level calendar in a project ..................................................................................................................... 75
Illustration 33 – Mockups ............................................................................................................................................................... 79
Illustration 34-Software project Development lifecycle ..................................................................................................... 85
Illustration 35-Scrum of scrums ................................................................................................................................................... 98
Illustration 36-Coordination of sprints ..................................................................................................................................... 99

11.Changes With respect to the 2017 edition.

• 1.1: Improved explanation of Scrum history
• 1.8: New section
• 5.2.3.1: New section “Managing knowledge”
• 5.3: The explanation for the principle of "simplicity" is improved

• 6.2.1 New section "Office of Agile Project Management (APMO)"
• 6.3: Examples of some possible risks were added
• 7.16: New Practice

• 7.3.1.1 New explanation of the life cycle in software development projects.
• 7.5: Is Adds The deployment or implementation stage and their associated practices.
• 8: The Scrum guide for big projects is added
• were added Charts in the different sections of the book

• Is Made several improvements in Spanish translations
• Improvements were made in the global explanations of the book to make it more understandable
to the reader
www.certmind.org

Scrum - An Agile Approach To Manage Successful Projects English PDF

Uploaded by

Copyright:

Available Formats

Scrum - An Agile Approach To Manage Successful Projects English PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Scrum - An Agile Approach To Manage Successful Projects English PDF

Uploaded by

Copyright:

Available Formats

What is Scrum and what problem does it aim to solve?

What is Scrum and what problem does it aim to solve?

What are the roles in a Scrum team?

What are the roles in a Scrum team?

An Agile Approach To Manage Successful Projects

Scrum – An Agile Approach to Manage Successful projects

certified) and CM Scrum Expert.

1. Introduction to Scrum ...............................................................................................................................................................9

1.2-Definition of Scrum .............................................................................................................................................................. 10

1.4-Structure of the guide ......................................................................................................................................................... 11

1.5-Scrum Uses .............................................................................................................................................................................. 11

1.5.1-When to use agile methodologies?....................................................................................................................... 12

1.6-Guide Clarifications .............................................................................................................................................................. 12

1.7-Scrum Scalability ................................................................................................................................................................... 12

1.8-is Scrum implemented or adopted? .............................................................................................................................. 13

2. The Scrum Team ....................................................................................................................................................................... 13

2.1-The Product Owner .............................................................................................................................................................. 14

2.2 -The development team............................................................................................................................................... 15

2.2.1-size of the development team ................................................................................................................................. 16

2.3 Scrum Master (Scrum master) .......................................................................................................................................... 16

2.3.1-The Scrum Master service to the product owner ............................................................................................. 17

2.3.2-The Scrum Master service to the development team .................................................................................... 17

2.3.3-The Scrum Master service to the organization ................................................................................................. 18

2.4-The values of the equipment ........................................................................................................................................... 18

2.4.1 – Commitment ................................................................................................................................................................ 18

2.4.4 – Receptivity-Opening ................................................................................................................................................. 18

2.4.5 – Focus ............................................................................................................................................................................... 19

3. Events in Scrum ......................................................................................................................................................................... 19

3.1-the Sprint (sprint) .................................................................................................................................................................. 19

3.1.1-Considerations on the duration of the Sprint ................................................................................................... 20

3.1.2-Sprint Cancellation ....................................................................................................................................................... 20

3.2 – Planning Meeting of the Sprint ............................................................................................................................. 21

3.2.1-Event data ........................................................................................................................................................................ 21

3.3-Daily Scrum (daily scrum) .................................................................................................................................................. 22

3.3.1-Event data ........................................................................................................................................................................ 22

3.4 – Sprint Review Meeting ..................................................................................................................................................... 23

3.4.1 Event data ......................................................................................................................................................................... 23

3.5 – Sprint Retrospective meeting ....................................................................................................................................... 24

3.5.1-Event data ........................................................................................................................................................................ 24

4. The Artifacts in Scrum ............................................................................................................................................................ 25

4.1-Product Backlog .................................................................................................................................................................... 25

4.2-Sprint Backlog ........................................................................................................................................................................ 26

4.3-Information emitters ............................................................................................................................................................ 27

4.3.1-Scrum Board ................................................................................................................................................................... 27

4.3.2-Burndown Sprint Chart ............................................................................................................................................... 28

4.3.3 – Cumulative Flow chart ............................................................................................................................................. 29

4.4 – Registration of obstacles/impediments .................................................................................................................... 30

5. Principles of Scrum .................................................................................................................................................................. 30

5.1 -Empirical Control of processes (1) .......................................................................................................................... 30

5.2 – Self-Organization (2) .................................................................................................................................................. 32

5.2.1-Team Collaboration ..................................................................................................................................................... 33

5.2.2-collaboration with the client ..................................................................................................................................... 34

5.2.3-Multifunctional equipment ....................................................................................................................................... 34

5.2.4-Collective ownership of the product ..................................................................................................................... 35

5.2.5 – Team Motivation ........................................................................................................................................................ 35

5.3 – Simplicity (3) .................................................................................................................................................................. 37

5.3.1-Simple design ................................................................................................................................................................. 37

5.3.2-use of software tools ................................................................................................................................................... 37

5.3.3-Is it worth working with processes? ...................................................................................................................... 38