Uploaded byDhaval Panchal
Agile 101 Basic Measurement
The document introduces key concepts and metrics related to Agile software development, including burn-down and burn-up charts, and team velocity. It emphasizes the importance of measuring progress through working software and provides guidance on effectively utilizing these metrics for team coordination and process improvement. Various pitfalls to avoid during sprint measurements and methods to enhance team performance are also discussed.
More Related Content
Similar to Agile 101 Basic Measurement
Editor's Notes
- #11 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
- #12 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
- #14 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.
- #25 Story level focus over task level focus. Focus on delivering business value rather than finishing tasks.
- #26 Tell story about Attenex where they behaved cross functionally to get manual test case execution to a day.
- #27 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.
- #28 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).
- #29 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
- #30 At least one story should have been accepted by the middle of the sprint
- #33 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
- #34 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
- #36 “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
- #37 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
- #43 Completed software represents business value
- #44 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.