• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile 101 Basic Measurement
 

Agile 101 Basic Measurement

on

  • 8,251 views

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 ...

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

Statistics

Views

Total Views
8,251
Views on SlideShare
8,018
Embed Views
233

Actions

Likes
10
Downloads
0
Comments
1

6 Embeds 233

http://www.dhavalpanchal.com 191
http://www.slideshare.net 20
http://dhavalpanchal.gettingagile.com 12
http://www.linkedin.com 6
http://www.slashdocs.com 2
https://twitter.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 Measurement Agile 101 Basic Measurement Presentation Transcript

  • 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
  • Agile Measurements • Provide transparency • Improve effectiveness • Enable continuous improvements Slide 12
  • What Do We Measure? • Introduction • Burn-down • Burn-up • Velocity Slide 13
  • Sprint Burn-down • Will the team meet its sprint goal? • Keeps track of effort remaining Slide 14
  • Glossary Terms Product Backlog Item (PBI) Task Task Task Task Task Task Task Slide 15
  • Sprint Burn-down: How to Measure? 180 • Initiate at Sprint 170 160 150 140 Hours Remaining planning 130 120 110 100 90 • Ideal trend line 80 70 80 50 40 • Track effort 30 20 10 remaining 2 1 3 4 5 6 7 8 9 Days Slide 16
  • Sprint Burn-down: Coordination • Monitor Burn-down 180 170 160 in daily Scrum 150 140 Hours Remaining 130 120 110 • Cone of +/- 20% 100 90 80 70 80 50 40 30 20 10 2 1 3 4 5 6 7 8 9 Days Slide 17
  • Burn Down Fast: Coordination 180 170 160 150 140 Hours Remaining 130 120 110 100 90 80 70 New Stories Pulled 80 50 40 30 20 10 2 1 3 4 5 6 7 8 9 Days Slide 18
  • Burning Up! Coordination 180 170 160 Reduced Scope? 150 Impediments Removed? 140 Hours Remaining 130 120 110 100 90 80 70 80 50 40 30 20 10 2 1 3 4 5 6 7 8 9 Days Slide 19
  • Sprint Burn-down: Process Tuning • Jumps or dips = 180 170 160 change in flow 150 140 Hours Remaining 130 120 110 100 90 80 70 80 50 40 30 20 10 2 1 3 4 5 6 7 8 9 Days Slide 20
  • 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 • Update remaining task hours daily 180 170 160 150 140 Hours Remaining 130 120 110 100 90 80 70 80 50 40 30 20 10 2 1 3 4 5 6 7 8 9 Days Slide 22
  • 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: Directly Affected By… • Team membership • Team’s domain and technology expertise • Collaboration skills • Environment • Impediments Slide 40
  • 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: Process Tuning Velocity 40 30 20 10 0 1 2 3 4 5 6 7 8 9 Sprints Slide 45
  • 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