4. Product Defini6on Team
• Product Owner may be part of the Product
Management func6on
• May receive input from mul6ple
– Product Managers
– Business Unit owners
– Analysts
– Architects
– Informa6on Architects
– Others
• How does the effec6ve Product Owner manage
all these inputs?
8. Affinity Es6ma6ng
Is this a
3 or a 5?
Ini6al Compara6ve
Story
What about
these Is this an
epics? 8 or a Is this a
13? 5 or an
8?
• Break up into small teams of 2‐4
• Discuss 2‐3 stories so there is a sense of them
• Find an ini6al compara6ve story
– If team is already Sprin6ng, find a small‐ish one already completed that was a really
good es6mate; use that es6mate
– Find a fully understandable story and fully task it out; call it either a 2 or a 3
• Without conversa6on, the en6re team puts all the stories on a big wall
– smallest at the right and largest on the le> compared to ini6al story
– Anyone can move anyone else’s story posi6on
• As ac6vity subsides, put a scaled number line up
• Secle on es6mates for boundary stories and epics
9. Mul6ple teams
• Synchronize within teams
• Synchronize across teams Daily Scrums
per Team
Scrum Team 1
9:00AM
9:30AM
9:30AM
Scrum Team 2 10:00AM
10:30AM
11:00AM
Scrum Team 3
Scrum of
Scrums
9
10. Three Levels of Synchroniza6on
Coordinating Scrum
Or MetaScrum
Scrum of
Scrums
Daily Scrums
Reproduced with permission from Mike Cohn,
Mountain Goat Software, 2003
10
11. The ABC’s of Scrum
Type A Type B Type C
Documents Product Backlog Release Roadmap Resource Plan
Sprint Backlog Product Backlog Release Roadmap
Burndown Chart Sprint Backlog Product Backlog
Burndown Chart Sprint Backlog
Burndown Chart
Ceremonies Sprint Planning Multi-level Planning MetaScrum
Daily Meeting Daily Meeting Multi-level Planning
Sprint Review Scrum of Scrums Scrum of Scrums
Sprint Review Daily Meeting
Sprint Review
Roles Product Owner Chief Product Owner Chief Product
Scrum Master Product Owners Owner
Team Uber Scrum Master Product Owners
Scrum Masters Uber Scrum Master
Teams Scrum Masters
Teams
Source: Jeff Sutherland
11
16. Scaling Recommenda6ons
• Correlate team organiza6on to subsystems or modules with
minimal cross‐over
• Implement development infrastructure to support the number and
loca6on of developers so it acts as a single development
environment
• Implement mee6ng and communica6on infrastructure op6mized
for number and loca6on of teams
• Develop standards, guidelines, training courses, templates, and
frameworks to minimize the coordina6on required for intended
scaling
• Develop coordina6on mechanisms for mul6ple teams
• Ensure each team has sufficient resources, carefully consider shared
resources
• Implement ways to develop a common culture across teams
16
17. Dispersed Team Recommenda6ons
• Co‐locate the team as o>en as possible, especially at incep6on and
key milestones
• Rotate members around
• Invest in (and plan for) tools that provide a shared environment
• Plan to experiment
• Establish a single global instance of project assets, easily accessible
by all
• Try virtual team building (team wiki w/bios & photos)
• Establish known hours, with as much overlap as possible
• Apply high cohesion and low coupling to alloca6on of work to sites
• Develop a shared team vocabulary
• Don't let anyone go dark
• Apply Scrum‐of‐Scrums concept when mass remote mee6ngs are
unproduc6ve
17
18. Notes on the Meta‐Scrum
• Unlike the Scrum of Scrums (where teams synchronize and coordinate with the purpose of
execu6ng on the Backlog),
• The Meta‐Scrum focuses on execu6ng on the roadmap and the strategy while elimina6ng side
channel conversa6ons about the releases and the roadmap. It is a gap reduc6on exercise.
• It is owned by the Chief Product Owner, who comes in with the plan. The par6cipants act like a
Board of Directors for the Product Owner who reviews and approves the plan.
• The par6cipants must have the authority to make decisions. If someone is missing, that person
must act in agreement with the decisions made in the mee6ng.
• Successful Meta‐Scrums provide consistent answers to the ques6on: quot;Does a Chief Product Owner's
Product Backlog have consent of all the Stakeholders?quot;
• The Chief Product Owner comes in to in the Meta‐Scrum with the plan, discussing what is meant by
plan, roadmap, product backlog and other names. Whatever you use, have it clearly defined.
• Indicators for when a Meta‐Scrum is needed:
– Organiza6on needs to reduce chaos
– Need consent at highest level of the organiza6on
– Balancing mul6ple projects
– Mul6ple organiza6onal areas need alignment
– You are in an environment where change happens (there are surprises)
hcp://scrumalliance.pbwiki.com/The+Meta‐Scrum 18
22. Crea6ng Memorable Visions
• Elevator Statement: • Product Box:
– FOR (target customer)
– WHO (statement of the need)
– THE (product name) is a
(product category)
– THAT (product key benefit,
compelling reason to buy).
– UNLIKE (primary compe66ve
alterna6ve),
– OUR PRODUCT (final
statement of primary
differen6a6on)
24. Product Roadmap
• The Product Owner:
– Communicates the whole
– Determines when releases are needed
– Determines what func6onality is sufficient
– Focuses on business value derived from the releases
• Delivery team
– Sees the whole
– Learns about the steps
– Learns the business priori6es
– Provides technical input to the roadmap
24
25. Product Roadmap – an example
April 8, ‘06 June 3, ‘06 July 8, ‘06 Aug 12, ‘06
Magnesium Aluminum Silicon Phosphorus
2006.2
2006.3
2006.4 2006.5
• For all users, improve • For all users, improve • For Rally customers, • For all users, enhance
customizaXon and usability, navigaXon and implement some of the flexibility of requirements
consistency. informaXon presentaXon. most requested hierarchy
• For Product Owners, enhancements • Provide Configurable
improve Roadmap, and EdiXons
Release Planning.
Agile PM Agile PM Agile PM Agile PM
• Custom Enumerations • Agile Product Manager • Defect Dropdown • Associate Iterations with
• Unified Backlog Planning Customization Releases
• New Release Status View System Mgmt. • Task Ranking
• Ajax-Enabled Detail Pages System Mgmt.
System Mgmt. System Mgmt.
• Hierarchical Stories
• Defect Close Rate Metrics
Comm. & Collaboration • Daily Defect Metrics
Comm. & Collaboration
Platform Comm. & Collaboration
Platform Comm. & Collaboration
• Improved UI • User Filterable
• UI Consistency Notifications
Responsiveness
• Improved Navigation Platform
• Tab Customization & Web
Platform
• Shared Custom Views Tabs
*Rally Agile Pro Edition only
26. Release as a series of Sprints
• A release comprises
mul6ple itera6ons
• Each itera6on can be
thought of as a same‐
sized box
• Stories of different
sizes (points) are put
into each box un6l it is
full
• The size of the box is
the planned velocity
Source: “Agile Es-ma-ng and Planning,” by Mike Cohn
27. An Agile Approach to Planning
Release
Condi6ons of Feedback
Sa6sfac6on
(backlog, budget,
schedule)
Release
Planning
IteraXon
Feedback
Condi6ons of
Sa6sfac6on (backlog,
schedule)
Itera6on Development
Product
planning increment
Source: “User Stories Applied” and “Agile Es-ma-ng and Planning,” by
Mike Cohn
28. An Agile Release Plan
PrioriXzed Product Backlog
Sprint n+1
As a frequent flyer, I want to…
The loca6on of the arrow is
As a frequent flyer, I want to…
determined by team velocity
As a frequent flyer, I want to…
and the number of remaining
As a frequent flyer, I want to…
itera6ons
Sprint n+2
As a frequent flyer, I want to…
As a frequent flyer, I want to…
As a frequent flyer, I want to…
As a frequent flyer, I want to…
Sprint n+3
As a frequent flyer, I want to…
As a frequent flyer, I want to… We’ll be here by the
As a frequent flyer, I want to…
planned deadline
As a frequent flyer, I want to…
As a frequent flyer, I want to…
As a frequent flyer, I want to…
As a frequent flyer, I want to…
As a frequent flyer, I want to…
Source: “Agile Es-ma-ng and Planning,” by Mike Cohn
29. Velocity
Velocity
40
Last observa6on = 36
Mean (Last 8) = 33
30
Mean (Worst 3) = 28
20
10
0
1 2 3 4 5 6 7 8 9
IteraXons
Source: “Agile Es-ma-ng and Planning,” by Mike Cohn
30. Deriving Dura6on Using Velocity
PrioriXzed Product Backlog
Itera6on 1
As a frequent flyer, I want to…
As a frequent flyer, I want to…
As a frequent flyer, I want to…
As a frequent flyer, I want to…
Itera6on 2
As a frequent flyer, I want to…
As a frequent flyer, I want to…
As a frequent flyer, I want to…
As a frequent flyer, I want to…
As a frequent flyer, I want to…
At our slowest velocity we’ll finish here
As a frequent flyer, I want to…
At our current velocity we’ll finish here
As a frequent flyer, I want to…
As a frequent flyer, I want to…
At our long‐term average we’ll finish here
As a frequent flyer, I want to…
As a frequent flyer, I want to…
As a frequent flyer, I want to…
As a frequent flyer, I want to…
31. Sezng up for Release Planning
• What is the purpose you hope to accomplish with Agile release
planning?
• Do you have a release theme or themes?
• What is the current state of the team?
• Do you have a velocity?
• Do you have a good Defini6on of Done?
• Do you have a Product Backlog?
• Is the Product Backlog Priori6zed by the Product Owner?
• Is the Product Backlog Es6mated by the whole team?
• Will the Product Owner(s) and whole team be in acendance?
• Will key members be in acendance (Architects, Opera6ons, QA,
Product Marke6ng, PMO, etc)?
• What have I not asked that is important to know?
32. Release Planning Session
• Conduct a Release Planning Mee6ng collabora6vely with the whole
team (product owner, delivery team, stakeholders)
• Plan for a 1‐day event (2 days for VERY large programs)
• Put each feature on an index card (post‐it notes)
• Physically arrange the priori6zed features into the Releases
• For the first release, physically arrange the priori6zed features into
the 3 or 4 groupings that represent the Sprints
• Post all decisions, risks, ac6ons (and if necessary, assump6ons) on
the wall
• Consider appropriate buffers and tradeoff matrix before
commitment
• Biggest risk: Product Owner must have a priori6zed Product
Backlog!!
36. Project repor6ng
• Minimize repor6ng
• What gets measured gets done
• Make it visible
• Possible metrics:
– Current burndown chart(s)
– Sprint goals and changes to the goals
– Defects – inflow, ou|low and # open defects per week
– Build quality per day/week
– Number of tests/tests passed per day/week
– Velocity over the last x Sprints
– Ac6on items, risks
36
39. Scrum Essen6als
• Elaborate features just‐in‐6me for the Sprint, not while
in the Product Backlog
• Product Owner stays engaged day‐to‐day for the
elabora6on and acceptance of features
• Teams are self‐organizing and cross‐func6onal:
everyone is responsible for the Sprint commitment
• Done means tested, integrated code & documenta6on
and accepted by the product owner
• Reduce defect logging by always moving to fully tested
code in the Sprint
• Ensure that so>ware is always close to shippable
39
40. What Can Cause
Scrum Adop6on to Fail?
• Ineffec6ve use of the retrospec6ve
• Inability to get everyone in the planning mee6ngs
• Failure to pay acen6on to the infrastructure required
• Bad Scrum Masters
• Unavailable product owner, or too many product owners who can’t
agree
• Rever6ng to form
• Obtaining only “checkbook commitments” from execu6ve
management
• Teams lacking authority and decision‐making ability
• Not having an onsite evangelist for remote loca6ons
• A culture that does not support learning
• The embrace of denial instead of the brutal truth
“11 Ways Agile Adop6on Fails” – Jean Tabaka
hcp://www.s6ckyminds.com/s.asp?F=S12384_COL_2
40
41. Cultural Change: The Hard Part
Old Organization New Organization
Centralized Distributed
Unified perspective Diversified perspective
Original meaning Emergent meaning
Analytical Creative
Analysis to action Learning by doing
Certain Uncertain
Strategy concept Local action
Authoritative Participative
Hierarchical Flat
Olson, Edwin & Eoyang, Glenda
41
43. Glossary of Terms
• Daily Scrum Mee6ng
– A fi>een‐minute daily mee6ng for each team member to answer three ques6ons: quot;What have I done since
the last Scrum mee6ng? (i.e. yesterday)quot; ; quot;What will I do before the next Scrum mee6ng? (i.e. today)quot; ;
quot;What prevents me from performing my work as efficiently as possible?quot; The ScrumMaster ensures that
par6cipants call sidebar mee6ngs for any discussions that go too far outside these constraints.
• Impediments
– Anything that prevents a team member from performing work as efficiently as possible is an impediment.
Each team member has an opportunity to announce impediments during the daily Scrum mee6ng. The
ScrumMaster is charged with ensuring impediments get resolved. ScrumMasters o>en arrange sidebar
mee6ngs when impediments cannot be resolved on the spot in the daily Scrum mee6ng.
• Product Backlog
– The product backlog (or quot;backlogquot;) is the requirements for a system, expressed as a priori6zed list of product
backlog Items. These included both func6onal and non‐func6onal customer requirements, as well as
technical team‐generated requirements. While there are mul6ple inputs to the product backlog, it is the sole
responsibility of the product owner to priori6ze the product backlog. During a Sprint planning mee6ng,
backlog items are moved from the product backlog into a sprint, based on the product owner's priori6es.
• Product Backlog Item
– In Scrum, a product backlog item (quot;PBIquot;, quot;backlog itemquot;, or quot;itemquot;) is a unit of work small enough to be
completed by a team in one Sprint itera6on. Backlog items are decomposed into one or more tasks.
44. Glossary of Terms
• Product Backlog Item Effort
– Some Scrum prac66oners es6mate the effort of product backlog items in ideal engineering
days, but many people prefer less concrete‐sounding backlog effort es6ma6on units.
Alterna6ve units might include story points, func6on points, or quot;t‐shirt sizesquot; (1 for small, 2 for
medium, etc.). The advantage of arbitrary units is they're explicit about the dis6nc6on that
product backlog item effort es6mates are not es6mates of dura6on. Also, es6mates at this
level are rough guesses that should never be confused with actual working hours. Note that
sprint tasks are dis6nct from product backlog items and task effort remaining is always
es6mated in hours.
• Product Owner Role
– In Scrum, a single person must have final authority represen6ng the customer's interest in
backlog priori6za6on and requirements ques6ons. This person must be available to the team
at any 6me, but especially during the sprint planning mee6ng and the sprint review mee6ng.
• Release
– The transi6on of an increment of poten6ally shippable product from the development team
into rou6ne use by customers. Releases typically happen when one or more sprints have
resulted in the product having enough value to outweigh the cost to deploy it.
• Release Burndown Chart
– In Scrum, the release burndown chart is a quot;big picturequot; view of a release's progress. It shows
how much work was le> to do at the beginning of each sprint comprising a single release. The
scope of this chart is a single release; however, a product burndown chart spans all releases.
45. Glossary of Terms
• ScrumMaster Role
– The ScrumMaster is a facilitator for the team and product owner. Rather than manage the team, the
ScrumMaster works to assist both the team and product owner in the following ways:
• Remove the barriers between the development and the product owner so that the product owner directly drives
development.
• Teach the product owner how to maximize return on investment (ROI), and meet his/her objec6ves through Scrum.
• Improve the lives of the development team by facilita6ng crea6vity and empowerment.
• Improve the produc6vity of the development team in any way possible.
• Improve the engineering prac6ces and tools so that each increment of func6onality is poten6ally shippable.
• Keep informa6on about the team's progress up to date and visible to all par6es.
• Sprint
– An itera6on of work during which an increment of product func6onality is implemented. By the book, an
itera6on lasts 30 days. This is longer than in other agile methods to take into account the fact that a
func6onal increment of product must be produced each sprint. The sprint starts with a one‐day sprint
planning mee6ng. Many daily Scrum mee6ngs occur during the sprint (one per day). At the end of the sprint
we have a sprint review mee6ng, followed by a sprint retrospec6ve mee6ng.
• Sprint Backlog
– Defines the work for a sprint, represented by the set of tasks that must be completed to realize the sprint's
goals, and selected set of product backlog items.
• Sprint Burndown Chart
– A sprint burndown chart (or quot;sprint burndown graphquot;) depicts the total task hours remaining per day. This
shows you where your team stands regarding comple6ng the tasks that comprise the product backlog items
that achieve the goals of the sprint. The X‐axis represents days in the sprint, while the Y‐axis is effort
remaining (usually in ideal engineering hours). Ideally the chart burns down to zero by the end of the sprint.
46. Glossary of Terms
• Sprint Goals
– Sprint goals are the result of a nego6a6on between the product owner and the development team.
Meaningful goals are specific and measurable. Instead of quot;Improve scalabilityquot; try quot;Handle five 6mes as many
users as version 0.8.quot; Scrum focuses on goals that result in demonstrable product. The product owner is
en6tled to expect demonstrable product (however small or flimsy) star6ng with the very first Sprint. In
itera6ve development, subsequent Sprints can increase the robustness or size of the feature set. Have your
team commit to goals that anyone will be able to see are met (or not met) at the end of the sprint. At sprint
review mee6ngs, the sprint demonstra6on is conducted a>er which the team asks the product owner
whether (s)he feels the goals were met. While some specific product backlog items may not be done at the
end of a sprint, it should be very unusual for a team not to meet its sprint goals. Scrum requires the team to
no6fy the product owner as soon as it becomes aware it will not meet its goals.
• Sprint Planning Mee6ng
– The Sprint planning mee6ng is a nego6a6on between the team and the product owner about what the team
will do during the next sprint. The product owner and all team members agree on a set of sprint goals, which
is used to determine which product backlog items to commit from the uncommiced backlog to the sprint.
The team will then break the backlog Items down into tasks.
• Sprint Retrospec6ve Mee6ng
– The sprint retrospec6ve mee6ng is held at the end of every sprint a>er the sprint review mee6ng. The team
and ScrumMaster meet to discuss what went well and what to improve in the next sprint. The product owner
does not acend this mee6ng.
47. Glossary of Terms
• Sprint Task
– In Scrum, a sprint task (or task) is a unit of work generally between four and sixteen hours.
Team members volunteer for tasks. They update the es6mated number of hours remaining on
a daily basis, influencing the sprint burndown chart. Tasks are contained by backlog items.
• Team
– A team (or quot;Scrum teamquot;) is op6mally comprised of seven plus or minus two people. For
so>ware development projects, the team members are usually a mix of so>ware engineers,
architects, programmers, analysts, QA experts, testers, UI designers, etc. This is o>en called
quot;cross‐func6onal project teamsquot;. Agile prac6ces also encourage cross‐func6onal team
members.
• Team Member
– In Scrum parlance, a team member is defined as anyone working on sprint tasks toward the
sprint goal.
• Velocity
– In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This
can be es6mated by viewing previous sprints, assuming the team composi6on and sprint
dura6on are kept constant. It can also be established on a sprint‐by‐sprint basis, using
commitment‐based planning. Once established, velocity can be used to plan projects and
forecast release and product comple6on dates.
48. Ar6cles
• “AgileEVM – Earned Value Management The Agile Way,” Tamara Sulaiman, Agile Journal, Jan. 8,
2007.
hcp://www.agilejournal.com/ar6cles/ar6cles/agileevm‐%96‐earned‐value‐management‐the‐agile‐
way.html
• “Agile Process and Self Organiza6on,” Ken Schwaber, www.controlchaos.com,
hcp://www.controlchaos.com/download/Self%20Organiza6on.pdf
• “Agile Top‐Down: Striking a Balance,” Bryan Stallings, Agile Journal, Mar.12, 2007.
hcp://www.agilejournal.com/ar6cles/ar6cles/agile‐top%11down%3a‐striking‐a‐balance.html
• “Establishing and Maintaining Top to Bocom Transparency Using the Meta‐Scrum,” Brent Barton,
Agile Journal, Oct. 6, 2007.
hcp://www.agilejournal.com/ar6cles/ar6cles/establishing‐and‐maintaining‐top‐to‐bocom‐
transparency‐using‐the‐meta%11scrum.html
• “Making the Date,” Ron Jefferies, xprogramming.com, Nov. 10, 2005.
hcp://www.xprogramming.com/xpmag/jatmakingthedate.htm
• “The New New Product Development Game,” Takeuchi and Nonaka, Harvard Business Review, Jan.
1, 1986.
hcp://harvardbusinessonline.hbsp.harvard.edu/b02/en/common/item_detail.jhtml?id=86116
• “Want Becer So>ware? Just Ask: Seven Things Project Customers Can Do,” Mike Cohn, Becer
So>ware, March 2004.
hcp://www.mountaingoatso>ware.com/system/ar6cle/file/9/WantBecerSo>ware.pdf
49. Online Presenta6ons
• “Agile Es6ma6on” by Mike Cohn
hcp://video.google.com/videoplay?docid=9061050925476245469&q=+site
%3Avideo.google.com&total=101&start=0&num=10&so=0&type=search&plindex=
3
• “Agile Project Management Planning and Budgezng” by David Hussman
hcp://www.infoq.com/presenta6ons/Agile‐planning‐and‐budgezng
• “Agile Quality: A Canary in a Coal Mine” by Ken Schwaber
hcp://www.infoq.com/presenta6ons/agile‐quality‐canary‐coalmine
• “Agile Retrospec6ves: Making Good Teams Great” by Esther Derby and Diana
Larsen hcp://video.google.com/videoplay?docid=‐7910406883328902493
• “How to Plan Projects with Distributed Teams” by Hubert Smits
hcp://video.google.com/videoplay?docid=2259483443972461251
• Interview: Jeff Sutherland on “Scrum and Not‐Scrum”
hcp://www.infoq.com/interviews/jeff‐sutherland‐scrum‐rules
• “ScrumMaster: Ken Schwaber’s Top Tips”
hcp://www.scrum‐master.com/top6ps/flash.html
• “The Roots of Scrum” by Jeff Sutherland
hcp://www.infoq.com/presenta6ons/The‐Roots‐of‐Scrum
