Participant Guide Delivering Agile Projects with …elearning.esi-intl.com/BlendedLearning/ILT/d54_v4_0/Linkspage/...&rs\uljkw (6, ,qwhuqdwlrqdo $xjxvw $oo uljkwv uhvhuyhg 1r sduw

$Page 1: Participant Guide Delivering Agile Projects with …elearning.esi-intl.com/BlendedLearning/ILT/d54_v4_0/Linkspage/...&rs\uljkw (6, ,qwhuqdwlrqdo $xjxvw $oo uljkwv uhvhuyhg 1r sduw$
Delivering Agile Projects with Scrum

Delivering Agile Projects with Scrum


© ESI International AGX:D54:EN:000 ver. 4.0

Introduction

1

Welcome to Delivering Agile Projects with Scrum

Emergency phone numberLocal emergency exit proceduresFloor and facility layoutStart and end expectationsBreaksAttendanceAgendaPassing this courseGround rules


Introduction

2

Course Overview

Module 1: Overview of ScrumModule 2: From a Vision to a RoadmapModule 3: Prioritizing the BacklogModule 4: Sprint Planning and Backlog GroomingModule 5: The Daily Stand-UpModule 6: Sprint Review and Retrospective


Introduction

3

Course Objectives

By the end of this course, you will be able to—Describe the Scrum framework from start to finishEvaluate the values and the principles that drive many of the agile practices within the Scrum frameworkExplain and create Scrum artifactsIdentify key roles and responsibilities within an agile project managed using ScrumApply the Scrum framework to future projects


Introduction

4

Introductions

Please share:Your name and roleYour current or most recent employer or job titleWhat your experience is with agileWhat you expect from this training experience


Module 1

1-1

Overview of Scrum


Module 1

1-2

Module Objectives

By the end of this module, you will be able to—Evaluate agile principles and valuesExplain Scrum and the Scrum frameworkDescribe Scrum values and pillarsIdentify roles and responsibilities in Scrum


Module 1

1-3

The Project Life Cycle


Module 1

1-4

Traditional and Agile Project Constraints


Module 1

1-5

Top Challenges/Drivers for Change

Traditional methods have a number of challenges, including:Initiating challenges: The team is not involved in initiation.Planning challenges: Sometimes, there is forced scope management.Execution challenges: Change requests are hard to implement and are discouraged.Monitoring and Controlling challenges: Variances (including improvements) are seen as a deviation.Closing challenges: The customer encounters the deliverable for the first time.


Module 1

1-6

History of the Agile Movement

In response to these challenges and failures, agile methods have been developed—emphasizing the incremental delivery of working products or prototypes.


Module 1

1-7

Creation of the Manifesto for Agile Software Development

The Manifesto for Agile Software Development—Is known also as the Agile ManifestoWas created in 2001 by a group of advocates of iterative and incremental development methodsIs the foundation document of the agile movement, which sets forth the underlying philosophical concepts of agile project management and includes a set of 12 principles


Module 1

1-8

The Agile Manifesto

Manifesto for Agile Development"We are uncovering better ways of developing products by doing it and helping others do it. Through this work, we have come to value:

"Individuals and Interactions over processes and tools"Working products over comprehensive documentation"Customer collaboration over contract negotiation"Responding to change over following a plan

"That is, while there is value in the items on the right, we value the items on the left more."

1 www.agilemanifesto.org


Module 1

1-9

Agile Principles

1. "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. "Welcome [accept] changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. "Deliver working software [business value] frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. "Business people and developers [the team] 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 team is face-to-face conversation."1

1 www.agilemanifesto.org


Module 1

1-10

Agile Principles (continued)

7. "Working software [value delivery] 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 fine tunes and adjusts its behavior accordingly."1


Module 1

1-11

What Is Scrum?

A development framework based on empirical process control wherein cross-functional, self-organizing teams deliver working software every 30 days (or less).


Module 1

1-12

Scrum Said Simply...

“Scrum” is an iterative agile framework that is designed to deliver working software (or value) every 30 days (or less) and supports the practice of all agile principles and values

Scrum has the following:RolesCeremoniesArtifactsOutputs


Module 1

1-13

Values and Pillars of Scrum

Scrum PillarsTransparencyInspectionAdaptation

Scrum ValuesCommitmentOpennessFocusRespectCourage


Module 1

1-14

Exercise 1-1

Reflections on Agile and Scrum


Module 1

1-15

Scrum Artifacts


Module 1

1-16

Who Does What?

Roles Artifacts Ceremonies

Product owner Product backlog: What are we doing?/In what order?

Sprint planning: What are we doing next?

Team members

Sprint backlog: What are we doing now?Product increment: Delivered at the end of the sprint

Daily Scrum: How are we doing today?Sprint review: What did we do?Sprint retrospective: How can we improve?

Scrum masterBurn-down chart: How are we doing this sprint? This release?

Supports ceremonies to ensure fidelity to Scrum


Module 1

1-17

The Umbrella of Methods


Module 1

1-18

The Scrum Team


Module 1

1-19

Phases of Team Development


Module 1

1-20

Scrum Roles – Development Team

Development Team Character Traits:

Customer focusedSelf-organizingTeam playersCollaborativeAccountableGoal orientedInnovativeServant leaders

FocusedFlexibleSolution drivenCourageousKnowledge sharersEmpoweredValue drivenQuality conscious


Module 1

1-21

Scrum Roles – Development Team (continued)

The team—Is responsible for turning the product backlog items into increments of value for each sprint

Is cross-functional, 7 +/- 2Is dedicatedConsists of generalizing specialistsDelivers value in small chunksFocuses on the customerBuilds in qualityIs self-organizingIs empowered


Module 1

1-22

Scrum Teams

Self-organizing teams will—Commit to work and complete itCollaborate to find innovative solutionsUnleash creative passionBe active change agentsDrive for continuous improvementShare knowledge and mentor each otherDeliver value, not costs


Module 1

1-23

Scrum Roles – Product Owner

Product Owner Character Traits:

Customer focusedWell respectedTeam playerStrategicCollaborative facilitatorInfluencerGoal orientedPragmatic

Servant leaderChange championProtectiveSolution drivenStrong communicatorExcellent presenterValue drivenFocused


Module 1

1-24

Scrum Roles – Product Owner (continued)

The product owner—Is responsible for maximizing the business value delivered by the team

Is 1 person responsible for the backlogAccepts or rejects workSets clear expectations for acceptanceIs knowledgeable, empowered, and engagedColocates with the team as much as feasibleManages stakeholder and sponsor expectationsMotivates the team, celebrates success!Can have a team

Eliminates potential project wastes


Module 1

1-25

Scrum Roles – Scrum Master

Scrum Master Character Traits:

MentorMotivatorChange championProtectiveSolution drivenStrong communicatorSupportivePositiveServant leader

TeacherWell respectedTrustingGoal orientedTeam playerGood listenerFacilitatorPragmatic


Module 1

1-26

Agile Roles – Scrum Master (continued)

The Scrum master—Is responsible for facilitating the Scrum process and ensuring the team is delivering value

Facilitates the processHelps builds self-organizing teamsRemoves impediments; escalates to the product owner when neededHelps the team inspect and adapt the processEmpowers the team through servant leadershipHelps create visible information radiatorsProtects the team from disturbancesCoaches the team


Module 1

1-27

Other Roles Within Your Agile Projects

What is the role of the sponsor and stakeholders?What is the role of management?What is the role of the IT architect and control groups?What is the role of executives and leaders in agile?What are common, real-world agile role challenges?


Module 1

1-28

Scrum Roles – Best Practices

Product owners should not be Scrum masters.PMs should not be Scrum masters without an education on the nuances.Business analysts should not be the only ones who gather requirements.A product owner must have a decision-making ability or power.Testers should be part of the team.


Module 1

1-29

Scrum Roles – Best Practices (continued)

Create a sprint zero backlog (prioritized product backlog).Provide ongoing agile training for all your teams.Keep an improvement backlog.Rotate the role of Scrum master around the team.Empower your teams to make decisions.Encourage pairing and knowledge transfer.


Module 1

1-30

Key Messages

Agile methodologies are a response to traditional “waterfall” methodologies of product management and development.The Agile Manifesto calls out the specific values and principles of the agile movement.Scrum is a specific agile methodology underpinned by 3 pillars and 5 values.The Scrum process includes specific artifacts and ceremonies.The 3 roles of the Scrum methodology are product owner, Scrum master, and development team.


Module 2

2-1

From a Vision to a Roadmap


Module 2

2-2

Module Objectives

By the end of this module, you will be able to—Describe how release planning supports the project vision and its backlogDescribe release planning and why it is done

Describe sprint zero and its applicationCreate an agile project roadmap


Module 2

2-3

From Vision to Product Backlog


Module 2

2-4

Product Backlog


Module 2

2-5

User Story Life Cycle


Module 2

2-6

Release Planning


Module 2

2-7

What Is Sprint Zero?

Sprint zero answers the following questions:What is the business idea/vision of the project or product?What is the definition of done and criteria of success?Who is on the Scrum team?Does everyone know how to do Scrum?Who are our customers and or stakeholders?What does the team need to do to prepare for the first sprint?What does the organization need to do to prepare for the first sprint?What does the developer need to do before they write code?


Module 2

2-8

Sprint Zero Checklist

VisionRelease planPrioritized product backlogAgreed-upon story estimation techniqueDefined sprint lengthTeamTesting agreementsTeam environmentsArchitectureRisks and issuesResource management


Module 2

2-9

Roadmap

Not part of the Scrum framework Typically done after a team or organization has defined their vision for its project, product, or services


Module 2

2-10

Release Planning

VisionAre we clear on it?Who are our stakeholders?Who is the product owner?What are our products?

RoadmapWhat is the order in which we want to get things?Who is our Scrum master?Who is our Scrum team?

Release planHow do we want to package the product?When would we like to get the product/product increments?Is our product backlog ready?


Module 2

2-11



Module 2

2-12

Case Study 2-1

Roadmapping


Module 2

2-13

Key Messages

A backlog is a list of working items that will be developed by the team in sprints.The backlog is developed by turning the vision into a roadmap, which, in turn, is split into releases.Before actually starting the project, it is recommended to do a sprint zero to make sure that everybody is on the same page and that the team has everything they need to start working.


Module 3

3-1

Prioritizing the Backlog


Module 3

3-2

Module Objectives

By the end of this module, you will be able to—Describe the MoSCoW (must have, should have, could have, won't have) and Kano methods used to prioritize your backlogCreate a sprint calendarExplain user stories and their importance in a Scrum projectWrite user stories using the INVEST (independent, negotiable, valuable, estimable, small, testable) model, the 3Cs (card, conversation, and confirmation), and the user story template


Module 3

3-3

Prioritization

How much should I prioritize?

When should I prioritize?


Module 3

3-4

Prioritization Techniques – MoSCoW

MoSCoW method:Must haveShould haveCould haveWon’t have


Module 3

3-5

Prioritization Techniques – Kano Model

Kano: Uses need and satisfaction to derive—

DelightersPerformance attributesBasic attributes


Module 3

3-6

Sprint Calendar


Module 3

3-7

How Long Should My Sprint Be?

Recommend 1–4 week iterations.Determine per project:

Supporting unique needs of the project is paramount.Some determining factors include the following:

Length of projectProject typeFrequency of demos desired by the product ownerProduct owner tolerance for not adding stories

Examples:Longer sprints for very large projects (4 weeks)Political climates requiring frequent demos suggest shorter sprints (2 weeks).

1 Jeffries, Ron. “Essential XP: Card, Conversation, Confirmation.” XP Magazine, August 2001, p. 1.


Module 3

3-8

User Stories

One construct for writing user stories is the 3Cs:1

Card: The user provides his or her perspective in a brief, simple requirement statement.Conversation: A story is an invitation for a “face-to-face” conversation.Confirmation: Each story should have a definition of “done,” which means when the product owner will accept the story.


Module 3

3-9

User Story


Module 3

3-10

User Story Formula

Follow the INVEST guidelines for good stories:


Module 3

3-11



Module 3

3-12

Case Study 3-1

Writing User Stories


Module 3

3-13

Scrum of Scrums


Module 3

3-14

Advanced User Story Techniques

Epics are either compound or complex:Compound: More than 1 independent story contained withinComplex: 1 really big independent story that must be broken down to reduce its complexity. There is an art to doing this.

Break large stories (epics) into smaller chunks using—Process-based slicingBusiness-rule slicingCRUD (create, read, update, delete)User or platform slicingAcceptance test slicing


Module 3

3-15

Sample Epic Breakdown – Compound

Course Registration

As a course administrator, I want to load courses for the coming period so that students can register on a course.As a student, I want to register for a course so that I can ensure I can attend.As a course tutor, I want to view details of the course listings so that I can print registration reports.


Module 3

3-16

Sample Complex Stories

As an administrator, I want to enroll a new student into the

system.

As an administrator, I want to enter demographic information for a new student enrollment.As an administrator, I want to enter financial information for a new student enrollment.As an administrator, I want to enter previous course work information for a new student enrollment.


Module 3

3-17

Splitting Techniques

Acceptance test based Note this is the most popular! Review the acceptance test for the story and determine which one(s) can be sliced into their own story.

Process based Draw a process diagram.Identify steps that offer a “complete,” valuable small deliverable.

Minimum end to end Use this minimal set of functionality to get the story working end to end; other stories to complete the feature could come later.

User/platform Break down stories by specific user types of specific platforms (iPhone, Internet Explorer, iPad)


Module 3

3-18

The Work Breakdown Process


Module 3

3-19

Example Theme>Epic>Story


Module 3

3-20

Example 2


Module 3

3-21

Acceptance Criteria

A set of statements that—Has a clear pass or fail resultSpecifies both functional and nonfunctional requirements for the specific use storyMakes it clear when a story is completed and working as expectedIs expressed in simple language the customer would useIs unambiguous about what is acceptable and what is notMust be actionableIs easily translated into manual or automated test case(s)Includes what is acceptable for open defectsIncludes some indication of an expected response timeStates intent but not the solutionAre phrased in solution-agnostic language


Module 3

3-22

Other Nonuser Story Considerations

Underpinning foundational storiesInfrastructure, technology foundational requirements

Clarifying nonfunctional storiesPerformance, usability, and so on

Mitigating risk—spike storiesResearch and analysis

Defining levels of defect acceptanceDefining maintenance and support requirements and so on


Module 3

3-23

Release Planning Meeting

After you have prioritized and estimated the backlog, your next effort is to build the actual plan. Here is generally what comes next:

Define what “done” means for your team.Determine your iteration length.Estimate the initial velocity.Map stories to iterations based on this estimate.Add fall-through, hardening, and prerelease iterations where needed.Arrive at an initial delivery date estimate.


Module 3

3-24

Case Study 3-2

Writing Acceptance Criteria


Module 3

3-25

Key Messages

The product backlog is prioritized by business value for the customer.If the backlog is too big for 1 team, then a Scrum of Scrums might be a solution.In order for user stories to be correct, they should follow these rules:

3Cs: card, conversation, confirmationINVEST (independent, negotiable, valued, estimable, small, testable)User story formula (As a USER TYPE, I want THIS FUNCTIONALITY in order to get THIS BENEFIT)

Sometimes, user stories are too big (complex or compound) and require splitting.Acceptance criteria are details added to a user story to decide when the story is done.


Module 4

4-1

Sprint Planning and Backlog Grooming


Module 4

4-2

Module Objectives

By the end of this module, you will be able to—Explain sprint planning and the importance of capacity planningDescribe and use story pointsEstimate user storiesEstimate team velocityExplain the purpose of backlog grooming and how it worksPerform backlog grooming


Module 4

4-3

Sprint Planning

Capacity – What is it?The team validates its capacity.The total capacity is used to ensure a sustainable pace.This will determine the velocity at which the team can plan.

Product backlog – What's the top priority?Validate the user story (requirement).Validate the acceptance criteria.Estimate the user story.

Sprint backlog – What’s going in the sprint?Break down the user story into tasks.Estimate the tasks in hours.Scrum team members sign up and commit to the work.


Module 4

4-4

Sprint Planning (continued)


Module 4

4-5

Estimating

“It is better to be roughly right than precisely wrong.”—John Maynard Keynes

Relative vs. absolute estimatingRelative estimating focuses on size and complexity, which happen at the story level.Absolute estimating focuses on ideal time, which happens at the task level.T-shirt sizing is often used for the relative estimation of bigger, more general work items like the epics.The modified Fibonacci scale is often used to estimate user stories.


Module 4

4-6

Relative Sizing

The key concept behind using “relative” sizing is to compare stories against each other.This approach does not aim for perfection or precision; rather, it aims for relative and simple measures of effort.“Story points” are a common unit of measure for sizing stories.Using points, we can measure velocity.


Module 4

4-7

Sizing Stories

Not time basedSize: How large is the story?Complexity: What is the effort involved?What is the risk?What is the impact?How uncertain is the story?What potential problems could arise?How much experience does the team have?


Module 4

4-8

Why Story Points?

Are easier and faster to measure and agree upon by the team than hours (the team owns the stories, so individual measurement units are useless)Drive cross-functional behaviorAvoid the waste in time and effort associated with getting detailed estimates that change anywayAre a pure measure of size (estimate by analogy: “this is like that”) and not timing (“this is when this will be done”)Are unlike ideal time/hour estimates, which will change drastically based on who is doing the work and their skillsAre unlike ideal time, which encourages specialization—very unproductive (waste)


Module 4

4-9

Story Points Scale for Epics

Modified Fibonacci scale for larger epics (themes, features)

This scale is also referred to as T-shirt sizing.


Module 4

4-10

Story Points – Fibonacci Scale

The Fibonacci scale is used for stories sliced to a small, granular level:

How many stories a team gets “done” in each sprint is its velocity.


Module 4

4-11

Planning Poker®

The rules of Planning Poker® are simple:Team gets together and discuss each story with the product owner until everyone has a clear understanding of it.Each person shows his or her card with his or her complexity vote but should not vote verbally so that others are not swayed by 1 person.If there is a major discrepancy, such as a 2 and an 8 vote, the parties hash it out by discussing their assumptions.The team votes again! (This can actually happen a few times.)A decision is reached with consensus!


Module 4

4-12

Team Velocity

Understanding the team’s velocity will enable release planning.Over time, use multiple data points to derive velocity:

Fastest paceAverage paceSlowest pace

Plan by using your rolling average.NOTE: The first sprints are not very relevant, and their lower velocity can corrupt the average.


Module 4

4-13

Team Velocity (continued)

Velocity is a team’s rate of progress.It is measured by the number of story points a team can finish in 1 sprint.Velocity is an estimate. It should be a number that reflects the number of stories the team committed to.Velocity can be a measure of performance because in time, based on all the improvements the team will be making, it should increase.


Module 4

4-14

Team Velocity (continued)

Factors affecting team velocity include:The number of resourcesHolidaysVacationInterruptionsMultitaskingThe skill and experience of team membersThe stage of team development

Over time, team velocity is derived from actual data.


Module 4

4-15

Estimating Initial Velocity

Ask the team the following question:“Which stories do you think you can commit to getting ‘done’ from this release during the first sprint? Be realistic in your commitment.”

These stories make up the team's initial velocity.


Module 4

4-16

Velocity and Points


Module 4

4-17

How the Velocity Affects the Release Plan

Teams with continuous release cycles build “rolling work plans.”


Module 4

4-18

Have Realistic Expectations!

Remember the team maturity stages?It takes 3 sprints before the team reaches the “performing” stage! This does not mean it will deliver nothing, but it does mean that the team needs time to work together and become effective.You can expect velocity to start low, get better, and sometimes slow down again, but it will finally become steadily efficient when the team is in its true “performing” stage.Even when performing, the team can expect to be asked for more points (velocity) if the product owner needs to deliver more.


Module 4

4-19

Case Study 4-1

Estimating User Stories


Module 4

4-20

Advanced Estimating – Business Value

Business value should be determined relatively and should be justified in at least 1 category:

Generates money (new business or up sell)Saves moneyImproves customer satisfactionProvides market opportunitiesMeets complianceImproves operational efficiencyMitigates riskAllows for learning


Module 4

4-21

Backlog Grooming

Product backlogList any new stories.List any new dependencies.Write the acceptance criteria.

Release planIs the release plan still valid?Is the criteria of success still valid?How are we tracking toward the release plan?

Preplan the next sprintThe product owner communicates the next sprint goal.The product owner identifies stories that meet that goal.The stories based on business value using MoSCoW and business value points.


Module 4

4-22

Backlog Grooming Drivers

A session driven by the product ownerAre the customer and stakeholders happy with the current progress?Are there any organizational blockers that need the product owner?Check the product backlog priority—is it still relevant?Do we have any new backlog Items?What would you like to see in the next sprint?Is the project/product success criteria still valid?Is the sprint length working?Do we have all the acceptance criteria for the next sprint stories?Are we acquiring any experience?How many new stories are we getting?What kind of feedback are we getting in the review?


Module 4

4-23

Case Study 4-2

Backlog Grooming


Module 4

4-24

Key Messages

Sprint planning is the intersection of what should be implemented in the next sprint and how it will get done.The output of sprint planning is the sprint backlog.Stories are estimated using relative scales of story points.Velocity is the measure of points that a team can deliver in a sprint.The product owner grooms the backlog by adding new stories and reprioritizing existing ones.


Module 5

5-1

The Daily Stand-Up


Module 5

5-2

Module Objectives

By the end of this module, you will be able to—Describe the purpose and features of a daily scrumExplain the best practices of a daily scrum


Module 5

5-3

Daily Stand-Up/The Daily Scrum

The daily Scrum—Is a short-term planning toolFacilitates team-to-team and intra-team communication

It lets teams—Discuss project progressIdentify shared dependenciesIdentify project roadblocksRefine schedulesRemain synchronized with one another


Module 5

5-4

Daily Scrum


Module 5

5-5

Best Practices for a Daily Scrum

A daily Scrum is no more than 15 minutes.Only 1 person speaks at once around the room.All stand during the process.Any impediments not already dealt with are taken and dealt with by the Scrum master, with the appropriate involvement of team members and others.Impediments are never discussed in any detail other than to call them out,It is good practice for the Scrum master role in the daily Scrum to move around the team.


Module 5

5-6

Key Messages

The daily Scrum is a 15-minute meeting that facilitates the team's communication and keeps work moving and synchronized.The following 3 questions are answered by each team member:

What have you done since the last Scrum?What will you do until the next Scrum?What problems distract you from accomplishing the sprint goals?


Module 6

6-1

Sprint Review and Retrospective


Module 6

6-2

Module Objectives

By the end of this module, you will be able to—Describe a sprint reviewConduct a sprint reviewConduct a sprint retrospective


Module 6

6-3

Sprint Review

DemoThe team demonstrates a completed product increment to the customer.The customer either via the product owner or directly accepts or rejects the items.

ReviewWhat did we plan to do this sprint?What did we actually do?Is there a delta and why?

Customer satisfactionIs the customer happy with the progress?Does the customer desire any change?What feedback are we getting?


Module 6

6-4

Sprint Review (continued)

A brief forum to close out the iteration after you have performed a demo on the product increment

Move unfinished stories to the product backlog.Review task completion.Discuss any outliers.Agree as a team what was “done.”Prepare the demo.Ask 3 questions for a review:

What did we plan to do?What did we did we deliver?What is the delta and why?


Module 6

6-5

Case Study 6-1

Sprint Review


Module 6

6-6

The Sprint Retrospective

The sprint retrospective provides a time to review the team’s working practices and processes to ensure that they are as efficient as possible.It discusses—

What went well?What could have gone better?What could be improved upon in the next sprint? The next few?

There should always be things that can be improved.


Module 6

6-7

Best Practices for the Sprint Retrospective

Keep it structured and facilitated.Avoid personality issues.Focus on issues like—

Sprint lengthRealistic expectationsNew soft and technical skills neededNew efficienciesHow many extra points can be achievedHow we can work smarter


Module 6

6-8

Case Study 6-2

Sprint Retrospective


Module 6

6-9

Final Course Retrospective

Reflect on the content and think about—What did I learn about that I currently do well in my agile projects?What did I learn about that I could improve upon and need to study more?What did I learn about that I could implement immediately in my current or next agile project?


Module 6

6-10

Key Messages

The sprint review is the ceremony when the team shares publicly what it achieved in the last sprint.The sprint retrospective is the ceremony when the team distances itself from the product and focuses on itself as a team, working to improve processes and efficiency.


Return to Slide

Return to Slide

Return to Slide

Return to Slide

Return to Slide

Return to Slide

Return to Slide


Return to Slide





Documents

Participant Guide Delivering Agile Projects with …elearning.esi-intl.com/BlendedLearning/ILT/d54_v4_0/Linkspage/...&rs\uljkw (6, ,qwhuqdwlrqdo $xjxvw $oo uljkwv uhvhuyhg 1r sduw