Mod 8 DGM

Agile Project
ManagementMGMT-6061
Module 8
PMBOK 7th Edition

Sprint Review
Module 8
Learning Outcomes
Understand the steps and issues of a Sprint Review
including:
•Identification of the Participants
•Prework required
•How to Demonstrate the Product (the work)
•Sprint Review Issues
This slide presentation augments your Course and
Module Readings. Complete the module readings
before reading through this presentation.
PMBOK 7th Edition
• The PMBOK® Guide – 7th Edition is intended to document high-level
principles, across 8 performance domains, and to inform all project
practitioners about the key concepts which are influential to running a
successful project, regardless of the methodology used to administer
that project (i.e., predictive, incremental, iterative, etc.).
PMBOK 6th Edition
• Whereas the PMBOK® Guide – 6th edition is grounded in technical
processes, inputs, tools and techniques, and outputs for the project
manager, the PMBOK® Guide seventh edition is driven by skills and
resources for the team to deliver value-based outcomes. The most
significant difference between the PMBOK® Guide 7th and 6th editions
is the shift of focus from very technically driven processes and tools to
more over-arching principles anyone involved with project management
work can use to be successful.
PMBOK 7th Edition
• The seventh edition of the Guide builds on the Standard and is
structured not around Knowledge Areas and ITTOs but around Project
Performance Domains, a group of related activities that are critical for
the effective delivery of project outcomes. The Domains include
important management practices but are not prescriptive “how to’s.”
Each section explains why the specific domain is important for effective
project management.
PMBOK 7th Edition
Governing Principle
• Be a diligent, respectful, and caring stewards.
• Create a collaborative project team environment
• Effectively engage with stakeholders
• Focus on value
• Recognize, evaluate and respond to system interactions
• Demonstrate leadership behaviours
• Tailor based on context
• Build quality into processes and deliverables
• Navigate complexity
• Optimize risk responses
• Embrace adaptability and resilience
• Enable change to achieve the envisioned future state
PMBOK 7th Edition
PMBOK 7th Edition
PMBOK 7th Edition
• More of a focus on Agile Development
• PMBOK 7th Edition will be based on principles

rather than processes and it will be much
shorter than the current edition.
• Used with the 6th edition

The Sprint Cycle
• Planning meeting the first day
• Sprint execution every day of the sprint
• Stand up meeting every day
• Demo on the last day (The Sprint Review)
• Retrospective
The Sprint Review (the demo)
• Scrum is an iterative process, an inspect and adapt
process
• In order to provide feedback, stakeholders have to
“see” what’s being built
• The Sprint Review is the opportunity for the team to
“demo” what they’ve done to capture feedback
The Sprint Review (overview) 3 min
• Hold Better End-of-Iteration Reviews: Improving
Sprint Reviews
• 2:21 min
• https://www.youtube.com/watch?v=T56Y3JdUXMk
Participants
Who should attend the Demo?
•The Scrum team
•Internal stakeholders such as users, managers,
executives
•Other internal teams such as parallel Scrum teams, or
internal experts on processes
•External stakeholders such as customers or partners
•Some demo’s can be open to interested parties
Prework
• Whom to invite? Varies per Sprint
• Schedule in advance
• Ensure the work that is “done”, is actually done, the PO should
verify before any demo, that the work is done
• The Scrummaster will manage the demo as a meeting
• Who will be doing the actual demo
• Scheduled in advance, some participants may need 2 or 3
weeks notice to attend
DoD and Acceptance Criteria
• Only “done” work should be “demo’d” to users
• Work should meet Definition of Done DoD requirements
• DoD is a general checklist of all items being worked on in the Sprint
• The team typically ensures the DoD is “done”, but the PO can check as well
or may assume responsibility
• Specific work should meet it’s specific Acceptance Criteria
• Acceptance Criteria may include specific tests
• The PO typically ensures the criteria is “done”
• Ensure the work that is “done”, is actually done, it has to work..!!
DoD and Acceptance Criteria Examples
The project is a web software application.
•Acceptance Criteria for a user story for a specific web page. The
criteria might cover:
• What the layout of the fields and static text on the page will be
• The order of fields when the user presses the Tab key
• The graphics on the page including size and positioning
•Definition of Done (applicable to all web page stories)
• The web page will load in under 2 seconds
• Font styles and sizes will meet the standard for the app
• The web page will have been tested for loading on 3 browsers x, y and z
• Any foreseen error messages will have a help message
Demo Planning, Agenda
• Demo’s have to be planned
• Finished work is supposed to be “shippable”
• The agenda has to leave time for discussion and feedback
• The objective is to be transparent on what was done, and not
hide what wasn’t done
• Software demo’s may require significant set-up, is there even the
right sample data to show users software screens?
• Demo’s may require dry runs and practice (this would be an item
required in the Product Backlog
The Demo
• Overview the Sprint to the participants
• Articulate what Stories were in the Sprint
• Demo the Stories
• Discuss and capture feedback
• Adapt
What if You Can’t “Demo” It?
Architecture improvements?
•Only completed or “done” work should be shown at a

demo, and most work has acceptance criteria or tests
•Must be something that the customer can “see” or

“use” that they view as having value
Revise the Product Backlog
• Based on feedback, items can be added to the
backlog
• Based on feedback, some items scheduled for the
next Sprint, may be postponed or cancelled
• The Product owner still determines the priority
• Even if feedback seems far “down the road” it can still
be added to the backlog, but the PO may position it at
the bottom of the list
Sprint Reviews are “team critical” (3 min)
• Scrum: The Sprint Review Process

• 2:54 min
• https://www.youtube.com/watch?v=2Jhf7PcYrzY
Sprint Review Issues
Participant attendance
• Difficult to get feedback when the right people

aren’t there
• Not enough time is provide for participant feedback

Sprint Review Issues
The sign-off
• The PO determines if the work is done (before the
demo), via the DoD and acceptance criteria
• The demo objective is not to get “sign-off” by the
end users
• User feedback is the objective, which will result in
changes and additions to the Product Backlog –
and a better product
Other Module Activities
• Ensure your perform all the module
activities such as Dropboxes,
Discussion Threads, group work,
research – and the readings
Module 8
End of Module
Parts of this document were sourced from:
Essential Scrum - A Practical Guide to the Most Popular Agile Process

Author: Kenneth S. Rubin
Publisher: Pearson Education, Inc

Mod 8 DGM

Uploaded by

Copyright:

Available Formats

Mod 8 DGM

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mod 8 DGM

Uploaded by

Copyright:

Available Formats

Agile Project

PMBOK 7th Edition

• PMBOK 7th Edition will be based on principles

• Used with the 6th edition

•Only completed or “done” work should be shown at a

•Must be something that the customer can “see” or

• Scrum: The Sprint Review Process

• Difficult to get feedback when the right people

• Not enough time is provide for participant feedback

Essential Scrum - A Practical Guide to the Most Popular Agile Process

You might also like