Agile Project Management – SCRUM Methodology

https://marios.evripidou.me
1
Agile Project Management – SCRUM
An Introduction

2
Agile Manifesto
Working
Software
over comprehensive
documentation
Customer
Collaboration
over contract negotiation
Agile
Manifesto
Values
Individuals and
Interactions
over processes & tools
Responding to
Change
over following a plan

3
Twelve Principles of Agile Software
1. Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive
advantage.
3. Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the shorter
timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the
job done.
6. The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity – the art of maximizing the amount of work not done –
is essential.
11. The best architectures, requirements, and designs emerge from
self-organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

4
SCRUM in a nutshell
• SCRUM is a framework for developing, delivering, and sustaining complex products
• Can be used to address complex adaptive problems and deliver products of the highest possible value
• Founded on empiricism: knowledge comes from experience and making decisions based on what is known
• Employs an iterative, incremental approach to optimize predictability and control risk.
The three pillars of empirical process control
• Transparency: aspects of the process must be visible to those responsible for the outcome
• There must be a common language of the process that is shared by all its participants
• Those performing the work and those inspecting the resulting increment must share a common definition of “Done”
• Inspection: inspect the scrum artifacts and the progress toward a Sprint Goal frequently to detect undesirable variances.
• Adaptation: if an inspection shows that the process has deviated and that the resulting product will be unacceptable, then the
process must be adjusted as soon as possible to minimize further deviation.

5
The SCRUM Team
• The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.
• Scrum Teams are self-organizing and cross-functional.
• Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
• Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the
team.
• Product Owner: represents the customer's interests. They decide what the team will work on next, so the team's efforts stay
focused on high-priority tasks that create the most value. The product owner must always be available to provide input or guidance
to the development team. Product owners are not managers — scrum teams self-organize.
• Scrum Master: their #1 goal is to help the development team be self-sufficient. Scrum masters intercept and remove barriers to
team progress, and act as a buffer between the team and any outside forces that might interfere with productivity. They lead daily
stand-up meetings. While the product owner is responsible for what the team will produce, the scrum master oversees the how.
• Development Team: made up of cross-functional team members, so the group has all the necessary skills to deliver the final
product. The team focuses on only one project at a time; members don’t multitask or split their efforts between multiple projects.
Once the product owner makes an ordered list of what needs to be done, the development team decides how much they can
complete in a single sprint and plan accordingly.

6
Product Owner
• The sole person responsible for managing the Product Backlog.
• Product Backlog management includes:
• Clearly expressing Product Backlog items
• Ordering the items in the Product Backlog to best achieve goals and missions
• Optimizing the value of the work the Development Team performs
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
• Ensuring the Development Team understands items in the Product Backlog to the level needed
• The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains
accountable.
• The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee but those
wanting to change a Product Backlog item’s priority must address the Product Owner.
• For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are
visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of
requirements.

7
Development Team
• The team who does the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.
• They organize and manage their own work which optimizes the Development Team’s overall efficiency and effectiveness.
• Development Teams are:
• self-organizing: no one (not even the Scrum Master) tells them how to turn Product Backlog into Increments of potentially
releasable functionality
• cross-functional: they have all the skills as a team necessary to create a product Increment
• Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person
• Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture,
operations, or business analysis
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development
Team as a whole
• Team size is small enough to remain nimble and large enough to complete significant work within a Sprint.
• Less than 3 members decrease interaction and results in smaller productivity gains, and they may encounter skill constraints
• More than 9 members requires too much coordination as it generates too much complexity for an empirical process to be useful.
• Product Owner and Scrum Master roles are not included unless they are also executing the work of the Sprint Backlog

8
Scrum Master
• Promotes and supports the Scrum methodology
• Helps everyone understand Scrum theory, practices, rules, and values
• Servant-leader to the Scrum Team
• Helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.
Helps everyone change these interactions to maximize the value created by the Scrum Team.
Service to the Product Owner
• Ensure that goals, scope, and product domain are
understood by everyone on the Scrum Team
• Find techniques for effective Product Backlog management
• Help the Scrum Team understand the need for clear and
concise Product Backlog items
• Understand product planning in an empirical environment
• Ensure the Product Owner knows how to arrange the
Product Backlog to maximize value
• Understand and practice agility
• Facilitating Scrum events as requested or needed
Service to the Development Team
• Coach the Development Team in self-organization and
cross-functionality
• Helps the Development Team to create high-value products
• Remove impediments to the Development Team’s progress
• Facilitate Scrum events as requested or needed
• Coach the Development Team in organizational
environments in which Scrum is not yet fully adopted and
understood.
Service to the Organization
• Lead and coach the organization in its Scrum adoption
• Plan Scrum implementations within the organization
• Help employees and stakeholders understand and enact
Scrum and empirical product development
• Cause change that increases the productivity of the Scrum
Team
• Work with other Scrum Masters to increase the
effectiveness of the application of Scrum in the organization.

9
The SCRUM Process
Sprint
Planning
Sprint Daily Scrums & Development Work Sprint Review
Sprint
Retrospective
Sprint
• A sprint consists of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective
• All events are time-boxed and each event is a formal opportunity to inspect and adapt something
• The length of a sprint is one month or less and has a consistent duration throughout a development effort
• If longer the definition of what is being built may change, complexity may rise, and risk may increase
• Limits the risk to one calendar month of cost
• A new Sprint starts immediately after the conclusion of the previous Sprint
• Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment
• During the sprint, a “Done”, useable, and potentially releasable product Increment is created
• During the Sprint no changes are made that would endanger the Sprint Goal, quality goals do not decrease, and scope may be clarified and re-
negotiated between the Product Owner and Development Team as more is learned

10
Sprint Planning (1)
• During Sprint Planning the Scrum Team plans the work to be performed in the Sprint
• It is time-boxed to a maximum of eight hours for a one-month Sprint
• The Scrum Master ensures that the event takes place, that attendants understand its purpose and keeps it within the time-box
• Sprint Planning answers the following:
• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?
Topic One: What can be done this Sprint?
• Takes as inputs the Product Backlog, the latest product Increment, the projected capacity and past performances of the Development Team
• The Scrum Team collaborates on understanding the work of the Sprint
• The Product Owner discusses the objective for the Sprint and which Product Backlog items need to be completed to achieve it
• The Development Team works to forecast the functionality that will be developed during the Sprint
• Only the Development Team can assess the number of items selected from the Product Backlog they can accomplish for the Sprint
• The Scrum Team crafts a Sprint Goal which is the objective that will be met within the Sprint through the implementation of the Product
Backlog, and it provides guidance to the Development Team on why it is building the Increment.

11
Sprint Planning (2)
Topic Two: How will the chosen work get done?
• Takes as inputs the Sprint Goal and the Product Backlog items for the Sprint
• The Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint
• The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog
• The Development Team designs the system and plans the work needed to convert the Product Backlog into a working product Increment
• The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and throughout the Sprint
• The Product Owner can help clarify the selected Product Backlog items and make trade-offs if required
• If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the
Product Owner
• The Development Team may also invite other people to attend to provide technical or domain advice
• By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to
work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment
• By the end of the meeting the Development Team has work planned for the first days of the Sprint

12
Daily Scrum
• A 15-minute time-boxed event held every day of the sprint where the Development team plans the work for the next 24 hours
• Held at the same time and place each day to reduce complexity
• The Development Team inspects the work since the last Daily Scrum and forecasts the upcoming Sprint work
• The Development Team inspects the work toward the Sprint Goal and how progress is trending toward completing the work in the Sprint
Backlog
• The structure of the meeting is set by the Development Team and can follow a question or discussion-based approach:
• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
• The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily
Scrum
• The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box
• The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the
meeting.
• Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote
quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

13
Sprint Review
• Held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed
• At most a four-hour meeting for one-month Sprints
• An informal meeting where the presentation of the Increment is intended to elicit feedback and foster collaboration
• Scrum Team and stakeholders collaborate about what was done in the Sprint and on what could be done next to optimize value
• The Scrum Master ensures that the event takes place, that attendees understand its purpose and teaches everyone to keep it within the time-box.
• The Sprint Review includes the following elements:
• The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”.
• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.
• The Development Team demonstrates the work that it has “Done” and answers questions about the Increment.
• The Product Owner discusses the current Product Backlog. If needed they project likely target and delivery dates based on progress to date.
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning.
• Review on how the marketplace or potential use of the product might have changed and decide what is the most valuable thing to do next.
• Review the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the
product.
• The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product
Backlog may also be adjusted overall to meet new opportunities.

14
Sprint Retrospective
• Held after the Sprint Review and prior to the next Sprint Planning
• At most a three-hour meeting for one-month Sprints
• Provides the opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint
• The Scrum Master ensures that the event takes place, that attendees understand its purpose and that is kept within the time-box
• The Scrum Master ensures that the meeting is positive and productive.
• The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.
• The purpose of the Sprint Retrospective is to:
• Inspect how the last Sprint went with regards to people, relationships, process, and tools
• Identify and order the major items that went well and potential improvements
• Create a plan for implementing improvements to the way the Scrum Team does its work
• The Scrum Master encourages the Scrum Team to improve within the Scrum process framework, its development process and practices to
make it more effective and enjoyable for the next Sprint.
• During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the
definition of “Done”, if appropriate and not in conflict with product or organizational standards.
• By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint.
Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself.

15
SCRUM Artifacts
• Scrum artifacts represent work or value to provide transparency and opportunities for inspection and adaptation
• Designed to maximize transparency of key information so that everybody has the same understanding of the artifact
• The Scrum Master
• works with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely
transparent.
• detects incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting
differences between expected and real results.
• works with the Scrum Team and the organization to increase the transparency of the artifacts. This involves learning, convincing, and
change.
• There are 3 Scrum Artifacts
• Product Backlog: An ordered list of everything that is known to be needed in the product.
• Sprint Backlog: The set of Product Backlog items selected for the Sprint
• Increment: All the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

16
SCRUM Artifacts – Product Backlog
• An ordered list of all features, functions, requirements, enhancements, and fixes to be made to the product in future releases
• It is never complete; it evolves as the product and the environment in which it will be used evolves
• The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
• Product Backlog items have a description, order, estimate, and value and can include test descriptions that will prove its completeness when
“Done.”
• Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.
• An ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.
• The Scrum Team decides how and when refinement is done.
• Refinement usually consumes no more than 10% of the capacity of the Development Team.
• Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
• Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones and easier to provide estimates
• Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.
• The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand
and select trade-offs, but the people who will perform the work make the final estimate.

17
SCRUM Artifacts – Sprint Backlog
• The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing
the Sprint Goal.
• Makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal
• To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective
meeting.
• The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum.
• The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint.
• The Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal
• As new work is required, the Development Team adds it to the Sprint Backlog
• As work is performed or completed, the estimated remaining work is updated
• When elements of the plan are deemed unnecessary, they are removed
• Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the
work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

18
SCRUM Artifacts – Increment
• An Increment is the sum of all the Product Backlog items 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 “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of
“Done.”
• The increment must be in useable condition regardless of whether the Product Owner decides to release it.
Monitoring Progress
Monitoring Progress Towards Goals
• At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every
Sprint Review.
• The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work
by the desired time for the goal. This information is made transparent to all stakeholders. (i.e. burn-downs, burn-ups, or cumulative flows)
Monitoring Spring Progress
• At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed.
• The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal
• By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

19
Definition of Done
• When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary
significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency.
This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.
• This definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose
of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.”
• Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to
immediately release it.
• If the definition of "Done" for an increment is part of the conventions, standards or guidelines of the development organization, all
Scrum Teams must follow it as a minimum.
• If "Done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must
define a definition of “Done” appropriate for the product.
• If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must
mutually define the definition of “Done.”
• Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.
• As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. New
definitions, as used, may uncover work to be done in previously “Done” increments.

20
References
[1] ‘Manifesto for Agile Software Development’ accessed on 24 December 2019
<https://agilemanifesto.org/>
[2] Ken Schwaber and Jeff Sutherland (2017) ‘The Scrum Guide’
<https://www.scrum.org/resources/scrum-guide>
[3] Emily Bonnie (2014) ‘Fundamentals of the Scrum Methodology‘ accessed on 24 December 2019
< https://www.wrike.com/blog/fundamentals-of-the-scrum-methodology/>

21
Thank You
W Emarios.evripidou.me marios@evripidou.me
Local Presence – Global Reach

Agile Project Management – SCRUM Methodology

More Related Content

What's hot (19)

Similar to Agile Project Management – SCRUM Methodology (20)

Recently uploaded (20)

Agile Project Management – SCRUM Methodology