Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Agile Development with Scrum
Transcript of Agile Development with Scrum
Originally devised by Harvard Business School professors Hirotaka
in 1986 as the "holistic" or "rugby" approach.
The New Product Development Game
Codified as Scrum by Ken Schwaber and Jeff Sutherland in 1993.
An agile scrum has three tangible deliverables, called artifacts.
Agile vs. Waterfall
The sprint planning meeting is attended by the product owner, ScrumMaster and the entire Scrum team.
Team selects items from the product backlog they can commit to completing
There are two defined artifacts that result from a sprint planning meeting:
A sprint goal
A sprint backlog
A list of all desired work on the project
Ideally expressed such that each item has value to the users or customers
Prioritized by the product owner
Reprioritised at the start of each sprint
Individuals sign up for work of their own choosing
Work is never assigned
Any team member can add, delete or change the sprint backlog
The most important Scrum artifact is the product increment.
Every sprint produces a product increment that must be of high enough quality to be given to users.
Defines the features of the product
Decides on release date and content
Responsible for the ROI
Prioritize features according to value
Accept or reject work results
Responsible for enacting Scrum values and practices
Shield the team from external interferences
Represents management to the project
Maine Agile User Group
Agile Certificate Program at USM
Mike Cohn’s website / books
Reach out to me
By: Miljan Bajic, PMP, PMI-ACP, CSP
Typically 5-9 people
Cross-functional: developers, testers, ex designers, etc.
Members should be full-time
May be exceptions (e.g., database administrator)
Teams are self-organizing
Ideally, no titles but rarely a possibility
Members should change only between sprints
Defined vs. Empirical Process
Overview of Agile Methodology
Scrum Framework Overview
Waterfall vs. Agile/Scrum
Portland Webworks Inc.
USM - Agile Dev with Scrum
Computer Information Systems & Comm.
Southern New Hampshire University
MBA in Project Management
PMP, PMI-ACP, CSP, CSM
Traditional / Waterfall
Well defined requirements upfront
Suited for situations where change is uncommon
A sequential process
Fast and flexible approach
Collaboration, adaptability and cont. improvement
Requirements are expected to evolve & change
Projects that deal with physical objects
Hardware installation project
Projects with defined tasks and phases
Project plans are repeatable
Requires substantial upfront planning
Scope changes can be slow + formal CCP
Less effective for service/product based projects
Best for project that deal with innovation-oriented projects
Allows for quick course correction
Empowers project teams to work creatively and efficiently
Not suited for projects with strictly defined steps
Uncertainty around scope and schedule (at first)
Requires vigilant requirements maintenance
Roots in Lean Manufacturing Principles
There are many specific Agile development methods.
Unification under Agile Manifesto
Mobile applications and websites
To prepare ships for deployment
In the automotive world
Waterfall Approach = Train Journey
Agile/Scrum Approach = Sailing Trip
Everyone answers 3 questions
What did you do yesterday?
What will you do today?
Are there any impediments in your way?
status for the ScrumMaster
They are commitments in front of peers
What works (clear wins)?
What doesn’t work so well?
What do we need to start doing?
Participants could include everybody in the project team
Decide what is DONE.
Team demonstrates working features
Only 100% completed work is demonstrated
Partially complete work is ignored
Direct feedback from stakeholders
Feedback incorporated into the backlog