This training is designed to equip participants

with an in-depth understanding of Agile

principles, frameworks, agile planning and
execution. Agile methodologies enable teams to
adapt to changing requirements. enhance
collaboration, and improve project outcomes.

📘 Intro: Agile
Methodologies
By the end of the course, participants will be able to:

 Comprehend Agile values, principles, and

mindset.
 Differentiate between Agile and
traditional project management.
 Identify and apply Agile frameworks such
as Scrum, Kanban, and SAFe etc.
TO: STAFF OF ISPMO AND  Implement Agile planning, estimation,
and execution techniques.
 Explain Agile tools for project tracking
PROJECT TEAM LEADERS
and collaboration.
 Comprehend the IS Agile framework
[2025]

Leoul Zewelde, Agile coach

IS and Digital Banking Transformation

PMP® - ICAgile ICP - PRINCE2 - PMI ACP -

ITIL®4 Leader: Digital and IT Strategy - CSPO
 DAY 1:
AGILE FUNDAMENTALS AND
PHILOSOPHY

1
Leoul Zewelde,
IS and DB Trans.
 SESSION 1: INTRODUCTION TO AGILE
(2 HOURS)

This session provides a foundational understanding of Agile methodologies. Participants will explore
the core concepts, history, and values that underpin Agile approaches.

1.1 WHAT IS AGILE?

DEFINING AGILE

Agile is an iterative and incremental approach to project management and software development that
helps teams deliver value faster and adapt to change.

 Iterative Development: Instead of completing a project in one go, Agile involves working in
short cycles called "iterations" or "sprints." Each iteration produces a working piece of the
product.
 Incremental Development: In each iteration, a new piece of functionality is added to what
was built before, gradually growing the final product.

Agile is also a mind-set, characterized by:

 Responding to Change: Agile recognizes that project requirements change. It values being
flexible over sticking to a rigid plan.
 Collaboration: Agile emphasizes teamwork and communication among everyone involved.
 Delivering Value: Agile prioritizes delivering working, useful features to customers early
and often.

Analogy: Building a House

 Waterfall (Traditional): Design the entire house (blueprint) upfront, then build the
foundation, walls, roof, and finish, only showing it to the owner at the end. Changes are
difficult and costly.

2
Leoul Zewelde,
IS and DB Trans.
  Agile:
o Iteration 1: Build the foundation and one room. Get owner feedback.
o Iteration 2: Add another room based on feedback.
o Iteration 3: Build the kitchen, etc. This allows for changes and ensures the owner gets
what they need.

What Agile Is Not

 Agile is NOT just tools or practices; the mind-set is essential.

 Agile is NOT chaotic; it has structure, but it's adaptable.
 Agile is NOT a cure-all; it improves projects but requires effort.
 Agile is NOT only for software.

HISTORY AND EVOLUTION OF AGILE

Agile arose to address the problems with traditional project management, especially in software
development.

 The "Software Crisis": In the 1990s, software projects often had:

o Delays
o Cost overruns
o Poor quality Waterfall's rigidity was a factor.
 The Agile Manifesto: In 2001, developers created the Agile Manifesto, outlining Agile's core
values and principles.
 Evolution of Agile: Agile has grown since 2001, with various frameworks (Scrum, Kanban,
XP, Lean) and applications beyond software.

EXAMPLES OF AGILE METHODOLOGIES

 Scrum: A framework for complex product development using "Sprints," roles (Product
Owner, Scrum Master, Team), and events (Planning, Daily Scrum, Review, Retrospective).
 Kanban: A method to visualize work and improve flow using a visual board and limiting
work in progress.
 Extreme Programming (XP): A software development methodology focused on code
quality and customer feedback, with practices like pair programming and test-driven
development.

3
Leoul Zewelde,
IS and DB Trans.
  Lean: A philosophy to maximize value and minimize waste, with principles like value stream
mapping and continuous improvement.

1.2 AGILE VS. TRADITIONAL (WATERFALL) APPROACHES

This section explores the key differences between Agile and traditional project management,
specifically the Waterfall model, and when to use each approach.

TRADITIONAL (WATERFALL) OVERVIEW

The Waterfall model is a linear, sequential approach where each phase must be completed before the
next begins.

 Phases: Requirements -> Design -> Implementation -> Testing -> Deployment
 Emphasis: Upfront planning and detailed documentation

Strengths of Waterfall:

 Predictability (for projects with stable requirements)

 Clear documentation

Weaknesses of Waterfall:

 Inflexible to change
 Late delivery of value
 Limited customer feedback until the end

AGILE OVERVIEW

Agile contrasts with Waterfall by being iterative and incremental.

 Key Aspects:
o Iterative and incremental

4
Leoul Zewelde,
IS and DB Trans.
 o Customer collaboration
o Adaptability
o Early and continuous delivery
 Key Concepts:
o Iterations (Sprints)
o Backlog
o Daily stand-ups
o Reviews and Retrospectives

WHEN TO USE WHICH APPROACH

The choice depends on factors like:

 Requirement stability
 Project complexity
 Need for innovation
 Customer involvement
 Agile is better for complex projects with changing needs.

1.3 THE AGILE MANIFESTO

The Agile Manifesto is the foundation of Agile, outlining its core values and principles.

INTRODUCTION TO THE AGILE MANIFESTO)

 Created in 2001 by software developers

 A statement of values and principles for better software development.

5
Leoul Zewelde,
IS and DB Trans.
AGILE VALUES

The Manifesto presents four core values:

 Individuals and interactions over processes and tools: Emphasizes communication and
collaboration.
 Working software over comprehensive documentation: Focuses on delivering useful
software.
 Customer collaboration over contract negotiation: Values continuous customer
involvement.
 Responding to change over following a plan: Prioritizes flexibility and adaptation.

AGILE PRINCIPLES

The Manifesto also includes twelve principles that support the values, such as:

 Customer satisfaction through early and continuous delivery

 Welcoming changing requirements
 Working software as the primary measure of progress

1.4 AGILE TERMINOLOGY AND KEY CONCEPTS

Understanding Agile terminology is crucial.

AGILE TERMINOLOGY

 Iteration/Sprint: A short, time-boxed period for completing work.

 Increment: A working piece of functionality delivered in an iteration.
 User Story: A user-centered description of a feature.
 Product Backlog: A prioritized list of work to be done.
 Sprint Backlog: Items from the Product Backlog selected for a Sprint.
 Daily Stand-up: A short, daily team meeting.
 Review: A meeting to demonstrate the Sprint's results.
 Retrospective: A meeting for the team to reflect and improve.

6
Leoul Zewelde,
IS and DB Trans.
KEY AGILE CONCEPTS

 Empiricism: Making decisions based on observation and experimentation.

 Self-organizing teams: Teams that are cross-functional and autonomous.
 Continuous improvement: Regularly reflecting and adapting to improve processes.

This comprehensive textbook-style material covers the entire "Introduction to Agile" session,
providing a solid foundation for participants.

7
Leoul Zewelde,
IS and DB Trans.
 SESSION 2: AGILE MINDSET AND
PRINCIPLES (2 HOURS)

This session delves into the Agile mindset and the core principles that guide Agile practices.
Participants will explore how these concepts shape Agile teams and their approach to work.

AGILE MINDSET AND PRINCIPLES

THE AGILE MINDSET

The Agile mind-set is a set of attitudes and beliefs that enable Agile teams to be successful. It's about
how individuals and teams think and interact, not just about following specific processes. Key
elements of the Agile mind-set include:

 Customer Focus: A deep understanding of customer needs and a commitment to delivering

value to the customer. Agile teams prioritize customer satisfaction and actively seek customer
feedback.
 Collaboration: Working together effectively as a team and with stakeholders. Agile
emphasizes open communication, shared responsibility, and mutual support.
 Adaptability: Embracing change and being willing to adjust plans and processes in response
to new information or evolving circumstances. Agile teams see change as an opportunity, not
a disruption.
 Continuous Improvement: A commitment to learning and getting better. Agile teams
regularly reflect on their work and identify ways to improve their processes, practices, and
skills.
 Empowerment: Giving teams the autonomy and authority to make decisions about their
work. Agile teams are self-organizing and take ownership of their outcomes.

8
Leoul Zewelde,
IS and DB Trans.
Mind-set Shift:

Adopting the Agile mind-set often requires a shift from traditional ways of thinking.

 From: Command-and-control leadership

 To: Servant leadership (leaders who support and empower their teams)
 From: Individual accountability
 To: Team accountability
 From: Focusing on tasks
 To: Focusing on delivering value
 From: Avoiding change
 To: Embracing change

THE AGILE PRINCIPLES

The Agile principles, outlined in the Agile Manifesto, provide guidance for embodying the Agile
mind-set. Each principle supports the Agile values and offers practical ways to apply them. Here are
some key principles:

1. Customer satisfaction by early and continuous delivery of valuable software: Deliver

working software frequently, from a couple of weeks to a couple of months, with a preference
to the shorter timescale.

 This principle emphasizes delivering value to the customer quickly and getting
feedback early.

2. Welcome changing requirements, even late in development. Agile processes harness

change for the customer's competitive advantage: Agile teams view change as an
opportunity to improve the product and better meet customer needs.

 This principle highlights Agile's flexibility and adaptability.

3. Working software is the primary measure of progress: Progress is measured by the

amount of working software that has been delivered, not by documentation or plans.

 This principle focuses on delivering tangible value to the customer.

9
Leoul Zewelde,
IS and DB Trans.
4. Business people and developers must work together daily throughout the project: Close
collaboration between business stakeholders and developers is essential for success.

 This principle underscores the importance of communication and teamwork.

5. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done: Agile teams are self-organizing and
empowered to make decisions.

 This principle highlights the importance of trust and empowerment.

6. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly: Agile teams continuously improve their processes and
practices through reflection and adaptation.

 This principle emphasizes continuous improvement.

7. Customer satisfaction by early and continuous delivery of valuable software: Deliver

working software frequently, from a couple of weeks to a couple of months, with a preference
to the shorter timescale.

 This principle emphasizes delivering value to the customer quickly and getting
feedback early.

8. Welcome changing requirements, even late in development. Agile processes harness

change for the customer's competitive advantage: Agile teams view change as an
opportunity to improve the product and better meet customer needs.

 This principle highlights Agile's flexibility and adaptability.

9. Working software is the primary measure of progress: Progress is measured by the

amount of working software that has been delivered, not by documentation or plans.

 This principle focuses on delivering tangible value to the customer.

10. Business people and developers must work together daily throughout the project: Close
collaboration between business stakeholders and developers is essential for success.

 This principle underscores the importance of communication and teamwork.

10
Leoul Zewelde,
IS and DB Trans.
 11. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done: Agile teams are self-organizing and
empowered to make decisions.

 This principle highlights the importance of trust and empowerment.

12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behaviour accordingly: Agile teams continuously improve their processes and
practices through reflection and adaptation.

 This principle emphasizes continuous improvement.

APPLYING AGILE PRINCIPLES

It's important to understand how to apply Agile principles in practice. This involves:

 Understanding the "Why": Don't just follow the principles blindly. Understand the
reasoning behind them and how they relate to the Agile values.
 Contextualization: Adapt the principles to your specific situation. There's no one-size-fits-all
approach.
 Experimentation: Be willing to try new things and see what works best for your team.
 Reflection: Regularly reflect on how well you're applying the principles and identify areas for
improvement.

11
Leoul Zewelde,
IS and DB Trans.
 SESSION 3: AGILE PLANNING AND
ESTIMATION (2 HOURS)

This session introduces Agile planning and estimation techniques, focusing on how Agile teams
effectively plan their work and estimate effort.

AGILE PLANNING AND ESTIMATION

AGILE PROJECT PLANNING

Agile planning is an adaptive approach to planning that embraces change and uncertainty. It involves
planning at different levels, from the overall product vision to daily team activities.

 Planning Levels:
o Product Vision: A long-term goal for the product.
o Product Roadmap: A high-level plan that outlines the evolution of the product over
time.
o Release Plan: A plan for delivering a set of features in a release.
o Sprint Plan: A detailed plan for a single Sprint.
o Daily Plan: The team's plan for the day.
 Key Planning Activities:
o User Story Writing: Creating user stories to describe features from the user's
perspective.
o Estimation: Estimating the effort required to complete user stories.
o Prioritization: Prioritizing user stories based on value and risk.

USER STORIES AND EPICS

 User Stories:
o Short, simple descriptions of a feature told from the user's point of view.
o Format: "As a [user role], I want to [goal] so that [benefit]."
o Example: "As a customer, I want to deposit a check using my phone so that I can save
time."

12
Leoul Zewelde,
IS and DB Trans.
  Epics:
o Large user stories that are broken down into smaller user stories.
o Example: "Mobile Banking" (Epic) -> "Deposit a check using my phone" (User
Story)
 Acceptance Criteria:
o Conditions that must be met for a user story to be considered complete.
o Help clarify requirements and ensure everyone has a shared understanding.
o Example: For "Deposit a check using my phone":
 The user can take a picture of the front and back of the check.
 The system can read the check amount.
 The funds are credited to the user's account.

PRODUCT ROADMAPS AND BACKLOGS

 Product Roadmap:
o A high-level visual plan that outlines the product's vision and evolution over time.
o Communicates the product's direction to stakeholders.
o Helps align development efforts with business goals.
 Product Backlog:
o A prioritized list of all the work that needs to be done in the project.
o Contains user stories, epics, bugs, and other tasks.
o Constantly evolving as new information becomes available.
 Sprint Backlog:
o The set of items from the Product Backlog that the team commits to completing
during a Sprint.
o Created during Sprint Planning.

AGILE ESTIMATION TECHNIQUES

Agile estimation is about providing relative estimates of effort, not precise predictions.

 Story Points:
o A unit of measure that expresses the relative size of a user story.
o Often based on the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.).
o Reflects complexity, effort, and risk.
 Planning Poker:
o A consensus-based technique for estimating user stories.
o Team members discuss the story and then simultaneously reveal their estimates.

13
Leoul Zewelde,
IS and DB Trans.
 o Differences in estimates are discussed to reach consensus.
 T-Shirt Sizing:
o A technique for estimating large items (e.g., epics) using T-shirt sizes (XS, S, M, L,
XL).
o Provides a quick and rough estimate.

VELOCITY AND CAPACITY PLANNING

 Velocity:
o A measure of the amount of work a team can complete in a Sprint.
o Used to forecast how much work the team can do in future Sprints.
 Capacity Planning:
o Determining the team's available capacity for a Sprint, considering factors like
availability and time off.
o Ensures that the team doesn't overcommit.

14
Leoul Zewelde,
IS and DB Trans.
DAY 2:
SCRUM DEEP DIVE &
AGILE PRACTICES

15
Leoul Zewelde,
IS and DB Trans.
 SESSION 4: SCRUM FRAMEWORK AND
ROLES (2 HOURS)

This session provides a comprehensive overview of the Scrum framework, its roles, events, artefacts,
and rules. Participants will gain a deep understanding of how Scrum teams organize and deliver value.

INTRODUCTION TO SCRUM

WHAT IS SCRUM?

 Scrum is a lightweight framework that helps people, teams, and organizations

generate value through adaptive solutions for complex problems.
 It is not a methodology but rather a framework for managing work.
 Scrum is based on empiricism, lean thinking, and iterative and incremental
approach.

o Empiricism: asserts that knowledge comes from experience and making

decisions based on observations.
o Lean Thinking: reduces waste and focuses on the essentials.
o Iterative and Incremental: delivers products in small pieces and continuously
improves them.

SCRUM VALUES

 Scrum values underpin the Scrum framework and guide the decisions, actions,
and behaviour.
 The Scrum Values are:

o Commitment: People personally commit to achieving the goals of the Scrum

Team.
o Courage: Scrum Team members have the courage to do the right thing and
work on tough problems.

16
Leoul Zewelde,
IS and DB Trans.
 o Focus: Everyone focuses on the work of the Sprint and the goals of the
Scrum Team.
o Openness: The Scrum Team and its stakeholders agree to be open about all
the work and the challenges.
o Respect: Scrum Team members respect each other to be capable, independent
people.

SCRUM FRAMEWORK

SCRUM ROLES

 Scrum defines three specific roles:

o Product Owner:

 Accountable for maximizing the value of the product resulting from

the work of the Scrum Team.
 Responsibilities include:
 Developing and explicitly communicating the Product Goal.
 Creating and clearly communicating Product Backlog items.
 Ordering Product Backlog items.
 Ensuring that the Product Backlog is transparent, visible, and
understood.

o Scrum Master:

 Accountable for establishing Scrum as defined in the Scrum Guide.

 Responsibilities include:
 Coaching the Scrum Team members in self-management and
cross-functionality.
 Helping the Scrum Team to focus on creating high-value
Increments that meet the Definition of Done.
 Causing the removal of impediments to the Scrum Team’s
progress.
 Ensuring that all Scrum events take place and are positive,
productive, and kept within the timebox.

17
Leoul Zewelde,
IS and DB Trans.
 o Developers:

 The people in the Scrum Team that are committed to creating any
aspect of a usable Increment each Sprint.
 Responsibilities include:
 Creating the plan for the Sprint, the Sprint Backlog.
 Instilling quality by adhering to a Definition of Done.
 Adapting their plan each day toward the Sprint Goal.
 Holding each other accountable.

SCRUM EVENTS

 Scrum events are time-boxed occurrences, meaning they have a maximum duration.
 The Scrum Events are:

o Sprint:

 A time-box of 1 month or less during which a usable and potentially

releasable Increment is created.
 Sprints have consistent durations throughout a development effort.
 All the events occur within the Sprint.

o Sprint Planning:

 The purpose of the Sprint Planning is to plan the work for the Sprint.
 It is time-boxed to a maximum of eight hours for a one-month Sprint.
 Sprint Planning answers the following:
 Why is this Sprint valuable?
 What can be Done this Sprint?
 How will the chosen work get done?

o Daily Scrum:

 The purpose of the Daily Scrum is to inspect progress toward the

Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the
upcoming planned work.
 The Daily Scrum is a 15-minute event for the Developers of the
Scrum Team.

18
Leoul Zewelde,
IS and DB Trans.
 o Sprint Review:

 The purpose of the Sprint Review is to inspect the outcome of the

Sprint and determine future adaptations.
 The Scrum Team presents the results of their work to key
stakeholders and progress toward the Product Goal is discussed.
 The Sprint Review is a four-hour event for a one-month Sprint.

o Sprint Retrospective:

 The purpose of the Sprint Retrospective is to plan ways to increase

quality and effectiveness.
 The Scrum Team16 inspects how the last Sprint went with regard to
individuals, interactions, processes, tools, and their Definition of
Done.
 The Sprint Retrospective is a three-hour event for a one-month
Sprint.

SCRUM ARTIFACTS

 Scrum’s artifacts represent work or value to provide transparency and opportunities

for inspection and adaptation.
 Scrum artifacts are designed to maximize the transparency of key information.
 The Scrum Artifacts are:

o Product Backlog:

 An emergent, ordered list of what is needed to improve the product.

 The Product Backlog is the single source of work undertaken by the
Scrum Team.

o Sprint Backlog:

 A detailed, real-time representation of the plan for the current Sprint.

 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.

o Increment:

19
Leoul Zewelde,
IS and DB Trans.
  A concrete stepping stone toward the Product Goal.
 Each Increment is additive to all prior Increments and thoroughly
verified, ensuring that all Increments work together.

SCRUM RULES

 Scrum’s rules bind together the events, roles, and artefacts, governing the
relationships and interactions between them.
 Scrum Rules are:

o How the roles interact with each other?

o How the events are used?
o How the artefacts are created and used?

20
Leoul Zewelde,
IS and DB Trans.
 SESSION 5: SCRUM ARTIFACTS AND
DEFINITION OF DONE (1.5 HOURS)

This session delves into the essential Scrum artifacts and the crucial concept of the Definition of
Done. Participants will understand how artifacts facilitate transparency and how the Definition of
Done ensures quality and completeness.

SCRUM ARTIFACTS

PRODUCT BACKLOG

 The Product Backlog is an emergent, ordered list of what is needed to improve the
product.
 It is the single source of work undertaken by the Scrum Team.
 Key characteristics:

o Emergent: It evolves as the product and its requirements evolve.

o Ordered: Items are prioritized to maximize value and achieve the Product
Goal.
o Detailed: Items at the top are usually more detailed than those at the bottom.

 Contains:

o Features
o User Stories
o Bugs
o Technical work

 Managed by the Product Owner.

SPRINT BACKLOG

o The Sprint Backlog is a detailed, real-time representation of the plan for the current
Sprint.
o It is the set of Product Backlog items selected for the Sprint, plus a plan for delivering
the product Increment and realizing the Sprint Goal.
o Created by the Developers during Sprint Planning.

21
Leoul Zewelde,
IS and DB Trans.
 o Key characteristics:
 Detailed: Provides a granular plan of how the Developers will deliver the
Sprint Goal.
 Dynamic: Updated throughout the Sprint as the Developers work and learn.
 Owned by the Developers.

INCREMENT

 An Increment is a concrete stepping stone toward the Product Goal.

 Each Increment is additive to all prior Increments and thoroughly verified, ensuring
that all Increments work together.
 It must be in usable condition and meet the Definition of Done.
 The sum of all Increments results in a working product.

DEFINITION OF DONE

UNDERSTANDING DEFINITION OF DONE

 The Definition of Done (DoD) is a formal description of the state of the Increment
when it meets the quality measures required for the product.
 It creates transparency by providing a shared understanding of what it means for work
to be complete.
 If a Product Backlog item does not meet the DoD, it cannot be released or even
presented at the Sprint Review.

IMPORTANCE OF DEFINITION OF DONE

 Ensures quality: Establishes a standard for what "done" means, leading to higher
quality Increments.
 Creates transparency: Provides clarity to all stakeholders on what to expect from each
Increment.
 Facilitates predictability: Helps the Scrum Team accurately forecast how much work
they can complete in a Sprint.
 Enables continuous delivery: Supports the ability to release working software
frequently.

22
Leoul Zewelde,
IS and DB Trans.
CREATING AND MANAGING DEFINITION OF DONE

 Created by the Scrum Team (often collaboratively).

 Adapted over time as the team learns and the product evolves.
 Applies to all work within a Sprint.
 Examples of DoD elements:

o Code is compiled, reviewed, and checked in.

o Unit tests pass.
o Acceptance tests pass.
o Documentation is updated.
o Integrated with existing system.
o Meets performance criteria.

23
Leoul Zewelde,
IS and DB Trans.
 SESSION 6: AGILE PLANNING AND
ESTIMATION (2 HOURS)

This session focuses on key Agile planning and estimation techniques, with a detailed exploration of
user stories, epics, story points, planning poker, and velocity.

USER STORIES AND EPICS

USER STORIES

 Short, simple descriptions of a feature told from the user's point of view.
 Format: "As a \[user role], I want to \[goal] so that \[benefit]."
 Emphasis on user needs: Focus on what the user wants to achieve, not on the
technical implementation.

Characteristics of a good user story (INVEST):

Independent: Can be developed and delivered independently.

Negotiable: Open to discussion and refinement.

Valuable: Provides value to the user.

Estimable: Can be estimated in terms of effort.

Small: Can be completed within a Sprint.

Testable: Has clear acceptance criteria.

Example: "As a customer, I want to deposit a check using my phone so that I can save time."

24
Leoul Zewelde,
IS and DB Trans.
EPICS

 Large user stories that are broken down into smaller user stories. Used to
represent a significant piece of functionality.
 Helpful for initial planning and road mapping.

Example: "Mobile Banking" (Epic) -> "Deposit a check using my phone" (User Story)

ACCEPTANCE CRITERIA

 Conditions that must be met for a user story to be considered complete.

 Define the boundaries of the story and ensure everyone has a shared understanding.
 Help with testing and verification.

Example: For "Deposit a check using my phone":

 The user can take a picture of the front and back of the check.
 The system can read the check amount.
 The funds are credited to the user's account.

AGILE ESTIMATION TECHNIQUES

STORY POINTS

 unit of measure that expresses the relative size of a user story.

 Reflects the overall effort, complexity, and risk involved in completing the story.

Relative estimation: Stories are compared to each other, not estimated in absolute time units.
Commonly based on the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21...)
 Each number is roughly 1.6 times greater than the previous one.
 This reflects the increasing uncertainty as estimates get larger.

Example:

 A small, simple story might be a "1".

 A story twice as complex might be a "2".
 A very complex story with many unknowns might be a "13" or "21".

25
Leoul Zewelde,
IS and DB Trans.
PLANNING POKER

 A consensus-based technique for estimating user stories.

 Involves the development team.

Steps:

1. The Product Owner or facilitator presents a user story.

2. Team members ask clarifying questions.
3. Each member individually selects a Story Point estimate (using cards with Fibonacci
numbers).
4. All team members reveal their estimates simultaneously.
5. If estimates differ, the team discusses the reasons behind their choices.
6. The process repeats until the team reaches a consensus.

Benefits:

 Encourages discussion and knowledge sharing.

 Helps to identify and address uncertainties.
 Improves the accuracy of estimates.
 Increases team buy-in.

VELOCITY

 A measure of the amount of work a team can complete in a Sprint.

 Used to forecast how much work the team can do in future Sprints.
 Calculated by summing the Story Points of all user stories completed in a Sprint.
 Tracked over multiple Sprints to establish a trend.

Capacity Planning:

 Determining the team's available capacity for a Sprint, considering factors like availability
and time off.
 Ensures that the team doesn't overcommit.

Velocity is used in conjunction with capacity planning to determine how many stories the team can
take on in the next Sprint.

26
Leoul Zewelde,
IS and DB Trans.
 SESSION 7: AGILE TOOLS AND
TECHNIQUES (1.5 HOURS)

This session introduces participants to essential Agile tools that support planning, tracking, and
collaboration. It also covers Continuous Integration and Continuous Delivery (CI/CD) and Agile
metrics for measuring team performance and progress.

AGILE TOOLS

JIRA

Jira is a powerful issue tracking and project management tool widely used in Agile development.

o Key Features:
 Backlog Management: Creating and prioritizing user stories, bugs, and tasks.
 Sprint Planning: Planning Sprints, assigning stories to Sprints, and managing
Sprint Backlogs.
 Workflow Management: Customizing workflows to track the progress of
work items (e.g., To Do, In Progress, Done).
 Reporting: Generating reports and dashboards to visualize progress, velocity,
and other metrics.
o Demo/Screenshots:
 Show a Jira board with user stories in different stages.
 Demonstrate how to create a user story and move it through a workflow.

TRELLO

o Trello is a visual collaboration tool that uses Kanban boards to organize tasks.
o Key Features:
 Boards, Lists, and Cards: Organizing work into boards, lists (e.g., To Do,
Doing, Done), and cards (tasks).
 Drag-and-Drop Interface: Moving cards between lists to indicate progress.
 Collaboration: Assigning team members to cards, adding comments, and
setting deadlines.
o Demo/Screenshots:

27
Leoul Zewelde,
IS and DB Trans.
  Show a Trello board with cards moving across lists.
 Demonstrate how to create a card and assign it to a team member.

ASANA

o Asana is a work management platform that helps teams organize and track their work.
o Key Features:
 Tasks and Subtasks: Breaking down work into tasks and subtasks.
 Projects: Organizing tasks into projects.
 Timelines: Visualizing project schedules.
 Reporting: Tracking progress and dependencies.
o Demo/Screenshots:
 Show an Asana project with tasks and subtasks.
 Demonstrate how to assign a task and set a due date.

AZURE DEVOPS

o Azure DevOps is a suite of development tools that includes features for Agile
planning, version control, CI/CD, and testing.
o Key Features:
 Azure Boards: Agile planning and tracking.
 Azure Repos: Version control (Git).
 Azure Pipelines: CI/CD pipelines.
 Azure Test Plans: Test management.
o Demo/Screenshots:
 Show an Azure DevOps board with work items.
 Demonstrate a basic CI/CD pipeline.

CI/CD AND AGILE METRICS)

CONTINUOUS INTEGRATION AND CONTINUOUS DELIVERY (CI/CD)

o Continuous Integration (CI):

 Developers frequently integrate their code changes into a shared repository.
 Automated tests are run to verify the changes.
 Helps detect and fix integration issues early.
o Continuous Delivery (CD):
 Automates the process of releasing software changes to production.
 Enables frequent and reliable releases.

28
Leoul Zewelde,
IS and DB Trans.
  Reduces the risk of deployment problems.
o CI/CD Pipeline:
 A series of automated steps that build, test, and deploy code changes.
 Stages: Code -> Build -> Test -> Deploy
o Benefits of CI/CD:
 Faster time to market
 Improved software quality
 Reduced costs
 Increased reliability

AGILE METRICS

o Metrics help Agile teams track their performance and identify areas for improvement.
o Key Agile Metrics:
 Velocity: The amount of work a team completes in a Sprint.
 Burndown Chart: Visualizes the remaining work in a Sprint.
 Burnup Chart: Visualizes the total work completed over time.
 Cycle Time: The time it takes for a task to move from "In Progress" to
"Done".
 Lead Time: The time it takes for a feature to go from "Requested" to
"Delivered".
o Using Metrics:
 Track metrics consistently over time.
 Use metrics to identify trends and patterns.
 Don't use metrics to punish or compare teams.
 Focus on using metrics to improve the process.

29
Leoul Zewelde,
IS and DB Trans.
 DAY 3:
AGILE IN PRACTICE &
ORGANIZATIONAL ADOPTION

30
Leoul Zewelde,
IS and DB Trans.
 SESSION 8: AGILE IN LARGE
ORGANIZATIONS & SCALING (2 HOURS)

This session explores the complexities of applying Agile principles in large organizations. It
introduces various scaling frameworks and addresses the challenges and best practices for successful
Agile adoption at scale.

AGILE IN LARGE

SCALED AGILE FRAMEWORK (SAFE)

SAFe is a comprehensive framework for scaling Agile to enterprise-level.

o It organizes Agile teams into Agile Release Trains (ARTs) that deliver value in
Program Increments (PIs).
o SAFe provides guidance for roles, events, and artefacts at the team, program, large
solution, and portfolio levels.

Key components of SAFe:

 Agile Release Train (ART): A team of Agile teams that plans, commits, and
executes together.
 Program Increment (PI): A time box during which an ART delivers an
Increment of value.
 SAFe Portfolio: Aligns strategy with execution, organizing ARTs around
value streams.

Video: A short video explaining the basics of SAFe.

LARGE-SCALE SCRUM (LESS)

LeSS is a framework for scaling Scrum while staying true to its principles.

o It focuses on scaling "up," not scaling "out," by applying Scrum principles at the
larger scale.
o LeSS consists of LeSS and LeSS Huge.

31
Leoul Zewelde,
IS and DB Trans.
  LeSS: For 2-8 teams.
 LeSS Huge: For organizations with more than 8 teams.

Key principles of LeSS:

 More with LeSS: Scale by simplifying, not adding complexity.

 Organizational design follows the product: Structure teams to align with
value streams.
 Purpose guides structure: The goal of the product determines the
organizational design.

NEXUS

Nexus is a framework for scaling Scrum developed by Scrum.org.

o It is built upon Scrum and introduces the Nexus Integration Team to coordinate the
work of multiple Scrum Teams.
o Nexus focuses on minimizing dependencies and integration issues between teams.

Key elements of Nexus:

 Nexus Integration Team: Responsible for ensuring that the integrated

Increment meets the Definition of Done.
 Nexus Sprint Backlog: A single backlog that represents the work of all teams
in the Nexus.
 Integrated Increment: The combined output of all Scrum Teams in the Nexus.

CHALLENGES AND BEST PRACTICES

CHALLENGES IN SCALING AGILE

 Organizational culture: Resistance to change, hierarchical structures, and lack of

management support can hinder Agile adoption.
 Coordination and communication: Maintaining alignment and effective
communication across multiple teams can be challenging.
 Dependencies: Managing dependencies between teams and components can become
complex.
 Consistency: Ensuring consistency in Agile practices and quality across the
organization.
32
Leoul Zewelde,
IS and DB Trans.
  Measurement: Measuring value delivery and progress at scale can be difficult.

BEST PRACTICES FOR SCALING AGILE

 Start small and iterate: Begin with a pilot program and gradually expand Agile adoption.
 Focus on value streams: Organize teams around value streams to deliver customer value
efficiently.
 Empower teams: Give teams autonomy and ownership to make decisions.
 Foster collaboration: Promote communication and collaboration across teams and
departments.
 Invest in training and coaching: Provide adequate training and coaching to support Agile
adoption.
 Adapt the framework: Customize the chosen scaling framework to fit the organization's
specific needs.
 Continuously improve: Regularly inspect and adapt the scaling approach based on
feedback and results.

33
Leoul Zewelde,
IS and DB Trans.
 SESSION-WISE RECAP
(REVIEW OF KEY LEARNINGS)

Session Key Topics

 What is Agile?
 Agile Manifesto values
Session 1  Agile vs. Waterfall

 Agile Mind-set
 Embracing change
Session 2  Servant leadership

 Agile Planning
 User Stories & Epics
Session 3  Agile Estimation

 Scrum Framework
 Scrum Roles
Session 4  Scrum Events

 Scrum Artifacts
Session 5  Definition of Done

 Agile Planning & Estimation

 Story Points
Session 6  Planning Poker

 Agile Tools
 CI/CD
Session 7  Agile Metrics

 Scaling Agile SAFe, LeSS, Nexus

Session 8  Challenges & Best Practices

34
Leoul Zewelde,
IS and DB Trans.
REVIEW: CBE SCRUM FRAMEWORK

KAHOOT QUIZ:

END.

35
Leoul Zewelde,
IS and DB Trans.