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?
You can change this under Settings & Account at any time.
Transcript of SCRUM 101
A Little Bit of History
Scrum in 100 Words
Initial scrums at Easel Corp in 1993
IDX and 500+ people doing Scrum
What is Scrum ?
It is a product management framework that you fill in that allows you to inspect and adapt
Easy to understand
Gabriele Giganti, CSPO
Program Manager @ eFront
“The New New Product Development Game”,
Hirotaka Takeuchi and Ikujiro Nonaka,
Harvard Business Review, January 1986.
“The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility.
Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.”
... develop "the kind of car that the youth segment would like to drive"...
1983 Honda Civic - Car of the Year in Japan
Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.
It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).
The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.
Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.
Scrum codified and presented at OOPSLA conference in Austin, TX in '95 with Sutherland
Scrum patterns in PLOPD4
Ken Schwaber and Mike Cohn
Co-founded Scrum Alliance in 2002, initially within the Agile Alliance
Manifesto for Agile Software Development
"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:"
Individuals and interactions
processes and tools
Responding to change
following a plan
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
Principles behind the Agile Manifesto
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
SCRUM is Used by
SCRUM is Used For
Video game development
FDA-approved, life-critical systems
Network switching applications
Some of the largest applications in use
the Joint Strike Fighter
24x7 systems with 99.999% uptime requirements
Be careful about predicting, particularly if it
involves the future
...and the biggest Scrum project success....
Traditional processes (e.g. waterfall) depend on prediction over long time scales.
They guess wrong about what is needed.
They miss the mark about when it will be done.
What is Agile?
Agile lays out the vision and then nurtures project resources to do the best possible to achieve the plan.
Agile is the art of possible.
The Agile heart is self-organization.
is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.
How does Agile Work?
Frequent inspection and adaption.
Emergence of requirements, technology and team capabilities.
and adaptation in response to what emerges using
Dealing with reality, not internal artifacts.
Defines the features of the product based on the
Prioritize features according to business value.
Adjust features and priority every iteration, as needed.
Accepts or rejects work.
Also can be a Product Owner team with a Chief Product Owner.
Maximizes ROI - accountable for value and ROI.
The "Answer Man" to the Development Team during the Sprint.
Decides which PBIs are releasable.
Ensures that one set of requirements drives development and that is no confusion from multiple bosses, different opinions, and interference from the outside.
Responsible for enacting Scrum values and practices
Removes obstacles to progress (impediments)
Ensures that the team is fully functional and productive
Enables close cooperation across all roles and functions
Shields the team from external interferences
Team's servant leader
Sustains culture and environment to optimize ROI
Organizes Sprint Planning
Facilitates daily Scrum meetings
May not direct the team nor tell them what to do
Estimates, selects and develops work items.
Manages a time-boxed development iteration to its forecast.
Team is cross-functional with all of the talents necessary to build a potentially shippable increment of product.
Stable team membership over time.
Delivers a potentially shippable product increment to the Product Owner once per Sprint.
DAILY SCRUM MEETING
Team selects items from the product backlog they can commit to completing.
Collaboratively, not done alone by the Scrum Master.
High-level design is considered and development team defines PBI implementation strategy.
Two parts ( 1-4 hours per part, depending on the Sprint length)
Product Owner must be prepared with an adequate Product backlog. If not.... go to the beach!!!
Estimates may be revised during the meeting
Team agrees how to build product functionality into a product increment in the next Sprint, thus creating a
THE DAILY SCRUM
Whole world is invited, but only team members can talk (Development team, Scrum Master and Product Owner)
Not for problem solving (focus is on visibility)
It helps avoid unnecessary meetings
Everyone answers 3 questions:
What did you do yesterday?
(What did I do yesterday that helped the Development Team meet the Sprint goal?)
What will you do today?
(What will I do today to help Development Team meet Sprint goal?)
Do you have anything in your way?
(Do I see any impediment that prevents me or Development Team to meet the Sprint goal?)
Done after every sprint
Whole team participates:
Product Owner ???
(two schools of thoughts)
Whole team gathers and discusses what they would like to:
We are not "Scrumming" without process improvement each Sprint.
1. Start doing
2. Stop doing
3. Continue doing
"Are we happy with the overall results so far?"
Team presents what it accomplished during the Sprint.
Presentation is in the form of demo of new features, fixed defects and/or underlying software architecture.
Maximum 1 hour presentation
NO POWER POINT!!!
Presented on the equipment where product was developed and tested.
Presented by Development Team to Product Owner and other stakeholders, including end users.
Everyone is invited.
Scrum is NOT
Trivial to implement
The final goal
A good product backlog supports communication between the Development Team, Product Owner and other stakeholders.
Efficient communication happens face to face - not in writing.
The form of the Product Backlog Items can support more or less structured communication.
The way Product Backlog is made has big influence on the team's velocity.
List of user stories, use cases, defects, enhancements and technical issues.
PBIs can be placeholders that are later defined as work .
Emergent, ordered, estimated - not categorized.
More detail on higher Backlog items.
One list for product for multiple teams.
Product Owner responsible for ordering.
Maintained and posted visibly.
Derived from Business Plan, Product Management or Vision statement.
PBIs are mostly in the cosumer space - what , not how.
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.
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 SPRINT GOAL
The Team commits to the team goal!
The Sprint Goal can be any coherence that causes the Development Team to work together rather than on separate initiatives.
The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the sprint.
Individuals sign up for work of their own choosing.
Work is never assigned !!!
This plan has enough details so that changes in progress can be understood in the Daily Scrum.
The Development Team modifies the Sprint Backlog throughout the Sprint, where necessary.
This emergence occurs as 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.
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.
The increment (or potentially shippable increment, PSI) is the sum of all the product backlog items completed during a Sprint and all previous sprints.
At the end of a sprint, the increment must be complete, according to the Scrum team's Definition of Done (DoD), and in a usable condition (shippable) regardless of whether the product owner decides to actually release it.
BURN DOWN CHART
BURN DOWN CHART
It is wastefull to track time consumed completing a user story or doing a task.
Time records are waste of time!!!
Focus should be on achieving the end date (end of Sprint).
Burn down charts are central Scrum "project management" tool
Focus is on delivery !!!
Cost management comes from estimation.
Velocity estimation comes from burn down chart.
BURN DOWN CHART
We should not care where we have been, since time spent is the time we can never recover.
We should care about the time that we will spend in the future, which is based on some form of estimate.
These estimates should be good enough to give Product Owner comfort that she/he can count on Development Team's forecast.
Over time Development Team becomes better and better at predicting where chart is the training tool for the team and Scrum Master's tool for inspection whether the Team is on track.
BACKLOG REFINEMENT (EX GROOMING)
Time for Development Team to work undisturbed.
The Sprint is the main unit of time boxing.
Having fixed time boxes establishes rhythm which helps set expectations over time - not only for the team but also for stakeholders, product owner and management as well.
If Sprint lasts longer than expected (two weeks/month), stakeholders and product owner migt suspect that team is guessing its work.
Most of the backlog should be prepared before Sprint planning.
Unprepared backlog makes for terrible meetings, it can demotivate whole Team and it can slow down the team.
PBIs are prepared in Backlog Refinement meeting
(also know as the "Wednesday meeting"). This meeting can be scheduled weekly or more frequently where needed.
It is Product Owner's responsibility to present Product Backlog with enabling specifications.
The Development Team estimates new PBIs.
Backlog Refinement is scheduled in advance - not on an interrupt basis.
Wideband Delphi technique that is adjusted.
Visibility of differences.
Drive to consensus.
Breaks down linear thinking.
It avoids "coloring" of estimates by a few key members of the team (architects, team leads, etc.).
It speeds up estimation process.
Jim Coplien's CSPO and CSM course
Mike Cohn @ www.moutaingoatsoftware.com
"Having a quick resourceful and adaptable character."
Lean production is an assembly-line methodology developed originally for Toyota and the manufacturing of automobiles. It is also known as the Toyota Production System or just-in-time production. Lean production principles are also referred to as lean management or lean thinking.
The core idea is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources.
A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste.
“The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.”
Ken Schwaber, 2004
"Vision is the art of seeing what is invisible to others."
The product vision paints a picture of the future that draws people in. It describes who the customers are, what customers need, and how these needs will be met.
It captures the essence of the product – the critical information we must know to develop and launch a winning product. Developing an effective product vision entails carefully answering the following questions:
1. Who is going to buy the product?
Who is the target customer?
2. Which customer needs will the product address?
3. Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product?
4. How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points?
5. What is the target time frame and budget to develop and launch the product?
Six Characteristics of Leading Companies
Self-organizing project teams
Overlapping development phases
Organizational transfer of learning