If burn down is burning down fastFirst: Meet sprint goal.Then: If team agrees and time permits take on additional storyAnimateTell story of team not committing to enough stories
Tell Story of Team discovering new tasks and taken on too much work; can not deliver what they have committed to.If burn down is burning up!Decide when to decide (+/- 20% cone may be helpful)Do something differentGet additional help from outsideDrop featuresBail – Abnormal termination
During retrospectives team reflects on events that caused significant jumps or dips in their burn down chart. Keeping track of impediments against burn down provides revealing information that can be actioned upon. For one team their burn down will spike every wednesday since the operations support people push production fixes every Wednesday night. The operations support will contact the team every Tuesday run fixes into staging environment which will lead to lots of issues that the scrum team will have to resolve. New work was pumped into the sprint since the team did not have a way to identify issues early on. After reviewing their impediment data against their burn down graph, this team started inviting production support person to their daily standup and worked with them to create automated test scripts that the team could run prior to submitting changes into production environment.
Story level focus over task level focus. Focus on delivering business value rather than finishing tasks.
Tell story about Attenex where they behaved cross functionally to get manual test case execution to a day.
Increased VisibilityInput for Product Backlog prioritizationVisibility to non technical stakeholders and product ownersEarly feedback on features, course corrections. May result in new product backlog items or change in priority for existing product backlog items.
Use information to reveal effectiveness of divide and conquer strategiesReveal silo-ed behavior early on. If most tasks are getting completed however none of the stories are accepted.Expose team burn up signature (pattern).
Do not abandon Sprint burn down chartDo not wait until the last day of sprint to seek acceptance on stories.At least one story should have been accepted by the middle of the sprint
At least one story should have been accepted by the middle of the sprint
Can think of this very naturally as “how fast the team can go” or “team capacity”Provides reliable guide because it’s based on actual, achieved rate of progressTrack record is the best predictor
Important: team does the estimatingTeam makes a commitment of how many points – will generally be close to previous velocityMeasured at end of each SprintUses definition of done All tasks completed Accepted by product owner
“Velocity is an attribute of the system that consists of both the team and the organizational environment around the team.”In a stable environment, velocity can be expected to increase over time Impediments: any obstacles to progress
Release planning: lets groups like sales, marketing, finance, customer service, documentation, technical support know what to expect in terms of timeframesCoordination with external teams:allows fulfillment of dependencies to be worked out with the calendarAllows estimation of how long it will take to do the intended amount of work
Completed software represents business value
Thanks Dhaval and Halim, that was great. The key to success with Agile is doing the fundamentals right, and then using “inspect and adapt” to improve your process. Today, we’ve seen an important aspect of that with these metrics and their uses. We’re going to take questions in a minute, but first, let me tell you a little about SolutionsIQ: We are a company that offers a full spectrum of services to develop software and fulfill technical talent needs, while improving our clients’ Agile knowledge and capabilities. Our clients include Fortune 500 companies like AT&T, Chevron, and Microsoft, as well as growth companies like Classmates.com and InfoSpace. We work together with VersionOne to equip companies with the tools and knowledge that companies need to succeed with Agile. We work with companies at every stage of Agile adoption, offering everything from introductory and certification training to full enterprise level management consulting services. SolutionsIQ’s nationally and internationally recognized Agile expertise grew out of our own use of Scrum and XP development practices in our Professional Services division, doing outsourced software development in Java and .NET. We’re not just talking ivory tower theory—these are hard-won lessons that we learned while delivering customer value in the form of working software. We also provide embedded development teams to help our customers meet their immediate business needs. The SolutionsIQ difference is that we will help you improve your own engineering practices while delivering quality software.
Agile 101: Basic Measurements
Dhaval Panchal, CST and Agile Coach
Halim Dunsky, Director of Delivery
Excellence
Slide 1
Dhaval Panchal
• Certified Scrum Trainer (CST) and Agile
coach
• Consults with organizations from mid-sized
product companies to the Fortune 100
• Experience in software
development, business and functional
analysis, Lean office
implementations, organizational
change, system architecture, business
intelligence, and project management
• Writes about software development and
coaching on his blog
(http://dhavalpanchal.gettingagile.com/)
• Received his B.S. in Engineering University of
Mumbai, India
Slide 2
Halim Dunsky
• Director of Delivery Excellence, responsible for
cultivating and retaining top-tier employees
and teams, and for ensuring successful delivery
of Agile software development and consulting
engagements
• Wide range of leadership and technical
positions at companies including Microsoft,
Deloitte & Touche, Bank of America
• Taught systems thinking to MBA students as
founding core faculty member at Bainbridge
Graduate Institute
• B.A. in Communications, Northwestern
University; M.A. in Organizational Systems,
Saybrook Graduate School; CSM, CSPO
Slide 3
What Do We Measure?
• Introduction
• Burn-down
• Burn-up
• Velocity
Slide 4
Measurements: Point of View
• Coaching Agile teams
• Actionable indicators
• Incomplete information
Slide 5
The Agile Manifesto
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 over processes and tools
Working software 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.
www.agilemanifesto.org
Slide 6
Measurements
Informational
Motivational
“Nothing about a piece
of information makes it
inherently motivational
Process Refinement Coordination
or informational.
Rather, it is the way in
which the information is
used that determines
the measurement
Agile Use
category.”
- Robert D. Austin [1996]
Slide 7
Agile Measurements
Knowledge work can not be measured and
managed as parts within a mechanistic system
Adaptive
Mechanistic
Slide 8
Agile Principles
• Build projects
around motivated
individuals
• Give them the
environment and
support they need
• Trust them to get
the job done
www.agilemanifesto.org/principles.html
Slide 9
Agile Principles
• Working software is
the primary
measure of progress
www.agilemanifesto.org/principles.html
Slide 10
The Scrum Framework
24 hours
Daily Scrum
Coordination Process
Meeting
Refinement
Sprint
Retrospective
Sprint
Typically 2
weeks to 1 Sprint Review
Sprint Planning Meeting
month in
duration
Vision Potentially
Sprint Backlog Shippable
Product
Increment
Product Backlog
Slide 11
Sprint Burn-down: Pitfalls to Avoid
• Do not hide Burn-
down charts. Post
them in the most
visible spot for the
team.
http://alistair.cockburn.us/Information+radiator
Slide 21
Sprint Burn-down: Pitfalls to Avoid
• Do not just focus on 180
170
160
taking tasks that you 150
140
Hours Remaining
are comfortable with 130
120
110
100
90
80
70
Abandoned
80
Tasks
50
40
30
20
10
2
1 3 4 5 6 7 8 9
Days
Slide 23
Sprint Burn-down
• Can we meet the
sprint goal?
• Represent effort
remaining
• Encourages early
course correction
Slide 24
What Do We Measure?
• Introduction
• Burn-down
• Burn-up
• Velocity
Slide 25
Sprint Burn-Up
• Will the team deliver
committed stories? 30
Story Points
• Incremental delivery
20
means “Done-
Done” 10
2
1 3 4 5 6 7 8 9
Days
Slide 26
Glossary Terms
Product Backlog Item
User Story
As a <user role>
I want <feature>
User Story
So that <value>
8
As a <user role>
I want <feature>
so that <value>
Sprint Planning
Source: “Agile Estimating and Planning,” by Mike Cohn
Slide 27
Glossary Terms: Done-Done
• Definition of Done: Helps us • Acceptance Criteria: Helps
build the thing right us build the right thing
(deliverables) (functionality)
Acceptance Criteria
Architecture •View status as “waiting for pickup,”
“en route” or “delivered”
Analysis
Infrastructure •Date of each step in route
•Estimated time of delivery
Design
Coding
Testing
Performance
Testing
Slide 28
Sprint Burn-Up: How to Measure
• Initial
– Cumulative total of 30
all story points
Story Points
committed at sprint 20
planning
• On going 10
– Cumulative total of
story points “Done
Done” during sprint. 2
1 3 4 5 6 7 8 9
Days
Slide 29
Sprint Burn-Up: Coordination
• Business value focus
Start END
“Scrumerfall” Stories
Completed = 0
Incremental Stories
Completed = 3
Slide 30
Sprint Burn-Up: Coordination
• Reduces work-in-
progress (WIP)
• Discourages
handoffs late in
sprint
Slide 31
Sprint Burn-Up: Coordination
• Early feature feedback
Slide 32
Sprint Burn-Up: Process Tuning
• Reveal
effectiveness of
divide and conquer
strategies
• Encourages role
sharing
Slide 33
Sprint Burn-Up: Pitfalls to Avoid
• Do not abandon sprint Burn-down chart
180
170
Hours Remaining
160
150 30
Story Points
140
130
120
110
100 20
90
80
70
80
50 10
40
30
20
10
2 2
1 1
3 4 5 6 7 8 9 3 4 5 6 7 8 9
Days Days
http://www.agilejournal.com/articles/columns/articles/274-the-agile-v-scorecard
Slide 34
Sprint Burn-Up: Pitfalls to Avoid
• Do not wait until the last day of sprint to
seek acceptance on stories.
30
Story Points
NOT “Done
Done!”
20
10
2
1 3 4 5 6 7 8 9
Days
Slide 35
Burn-Up Chart
• Early and
continuous
feedback
• Focus on delivering
business value
• Drives cross-
functional behavior
Slide 36
What Do We Measure?
• Introduction
• Burn-down
• Burn-up
• Velocity
Slide 37
Velocity
• Amount of product
backlog a team can
complete within a given
sprint
– Measured sprint by sprint
– Based on actual track record of a
team delivering working software
– Provides basis for planning
– Results, not effort
Slide 38
Velocity: How to Measure
• Team estimates Product Backlog Items
• Team pulls in Product Backlog Items to
Sprint Backlog during Sprint Planning
• Team executes on sprint
• Story points completed and accepted
count towards Sprint Velocity
Sprints Story Points Story Points Velocity
Committed Accepted
1 20 16 16
2 24 24 24
Slide 39
Velocity: Coordination
• Release planning
with key stakeholders
• Dependency management with
external teams
Slide 41
Velocity: Coordination
Prioritized Product Backlog
Sprint n+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…
Sprint n+2
As a frequent flyer, I want to…
The location 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…
Sprint n+3
iterations
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…
Source: “Agile Estimating and Planning,” by Mike Cohn
As a frequent flyer, I want to…
Slide 42
Velocity: Coordination
Prioritized Product Backlog
• Risk management
Iteration 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…
Iteration 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…
Slide 43
Velocity: Process Tuning
• Solid Agile teams have consistent velocity
(+/- 20%)
• Fluctuations? Look to stabilize
team, environment
• Velocity trending down or up? Look to
technical-debt handling, team processes
Slide 44
Velocity: Pitfalls to Avoid
• Velocity between teams is not
comparative or additive
• Velocity does not show relative
performance or productivity of teams
• Velocity does not imply commitment
• Do not use not-done work in velocity
calculations
Slide 46
Summary
• Burn-down tracks effort remaining
• Burn-Up tracks completed software
delivered
• Velocity tracks team history
of delivered software
Slide 47
• Founded: 1979
• Employees: 250+
• Headquarters: Redmond, WA
• Full range of technology
consulting services, from Agile
training and consulting to
software development and
talent acquisition
• Leading provider of Scrum
Certification Training
Slide 48
Agile Services at Every Stage
Slide 49
Questions & Answers
Slide 50
Upcoming SolutionsIQ Webinars
Presented by VersionOne
13 May Agile ROI Part II: Building the Business Case
for Agile
Soon Agile Portfolio Metrics: A Dashboard for
Executives
Soon Strategies for Maximizing Agile Portfolio
Value
Slide 51
Thank You
• Following this presentation, participants will
receive an email with links to a recording
and copies of today’s slides
• For more on SolutionsIQ
www.SolutionsIQ.com
info@SolutionsIQ.com
+1(800)235-4091
Slide 52
Agile teams collect metrics to provide information more
Agile teams collect metrics to provide information for coordination and process tuning. What are some of the basic measurements used in Agile development? How do I make these measurements? How should I use these measurements? What metrics can I use for project analysis? What are some of the pitfalls that should be avoided?
Topics will cover: Understanding the use of metrics in your environment Velocity, Burndown and Burnup less
0 comments
Post a comment