Burn Up and Burn Down An Overview of Scrum. Neal Kuhn Business Systems Architects, LLC

Transcription

1 Burn Up and Burn Down An Overview of Scrum Neal Kuhn Business Systems Architects, LLC Scrum Agenda (1) Setup (5) At the end of this segment, the project and slides are set up Agenda (5) At the end of this section, the team will understand the agenda of this presentation Scrum Definition (5) At the end of this section, the team will understand the name and that Scrum is a framework Roles (10) At the end of this section, the team will understand the roles in Scrum Development Team Product Owner Scrum Master Events/ceremonies (10) At the end of this section, the team will understand events in Scrum (Sprints) Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective 1

2 Scrum Agenda (2) Artifacts (15) At the end of this section, the team will understand the artifacts used in Scrum Product Backlog Sprint Backlog Product Increment Release and Sprint Burndown Monitoring Progress Burn Down vs. Burn Up Done (10) At the end of this section, the team will understand the concept of Done Definition of Done SCRUM Origin of Scrum A play in Rugby in which the two sets of forwards mass together around the ball and, with their heads down, and arms interlocked push to gain ground. How we define Scrum (n): An empirical FRAMEWORK within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. A key principle of Scrum is its recognition that during a project, customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the group s ability to deliver quickly and respond to emerging requirements. (Agile value 2) 2

3 Scrum / Agile Benefits The Success rate of waterfall is 11% The success rate of agile is 39%. 61% of agile teams cannot deliver so many teams are "Agile in Name Only. Most of them have no working product at the end of the sprint so they do not meet the second value of the Agile Manifesto. Even then, they reduce development costs by an average of 35%. Research in Silicon Valley showed that if a bug was not found and fixed inside a sprint, it took 24 times as long to find and fix three weeks later for developers building a web operating system. This finding has been replicated in Europe. So for complex products something that could be delivered in a month with Scrum would take 2 years without. For this reason, the CEO of Microsoft banned all test teams last year. So effectively, waterfall is banned at Microsoft. They can't compete with waterfall and neither can you. - Jeff Sutherland, Inventor and Co-Creator of Scrum ( 8/3/2015) Empiricism Scrum is Founded on Empirical Process Control Theory Three Pillars Transparency - Significant aspects of the process must be visible to those responsible for the outcome. Common standards, i.e.: A common language referring to the process must be shared by all participants; A common definition of Done"must be shared by those performing the work and those accepting the work product. Inspection -Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances. Inspection should not be so frequent that it gets in the way of the work. Adaptation -If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation. 3

4 SCRUM ROLES Three core roles and a range of ancillary roles core roles are often referred to as pigsand ancillary roles as chickens Pigs: Development ( or Scrum) Team Product Owner Scrum Master Everyone else is a chicken Development Team The Development Team consists of professionals who do the work of delivering a potentially releasable increment of Done product at the end of each Sprint. Only members of the Development Team create the Increment. They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment; Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule; Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis. 4

5 Development Team ( 2) No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn t allowed to act on what anyone else says. Product Owner The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: Clearly expressing Product Backlog items; Ordering the items in the Product Backlog to best achieve goals and missions; Ensuring the value of the work the Development Team performs; Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and, Ensuring the Development Team understands items in the Product Backlog to the level needed. 5

6 Product Owner (2) The Product Owner is one person, not a committee. For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner s decisions are visible in the content and ordering of the Product Backlog. Scrum Master The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master serves the Development Team in several ways, including: Coaching the development Team in self-organization and cross-functionality; Teaching and leading the Development Team to create high-value products; Removing impediments to the Development Team s progress; Facilitating Scrum events as requested or needed; and, Coaching the Development Team 6

7 Scrum Master -(2) The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. The Scrum Master serves the Product Owner in several ways, including: Helping find techniques for effective Product Backlog management; Clearly communicating vision, goals, and Product Backlog items to the Development Team; Teaching the Scrum Team to create clear and concise Product Backlog items; Understanding long-term product planning in an empirical environment;. SCRUM EVENTS/ Ceremonies Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. Scrum uses time-boxed events, such that every event has a maximum duration. This ensures an appropriate amount of time is spent planning without allowing waste in the planning process. Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt. 7

8 Scrum Events / Time Boxes Sprint Sprint Planning Meeting Developmental Work Daily Scrum / Standup Meeting Sprint Review Sprint Retrospectives Sprint The heart of Scrum is a Sprint, a time-box of one month or less during which a Done, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. During the Sprint: No changes are made that would affect the Sprint Goal; Development Team composition remains constant; Quality goals do not decrease; and, Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. 8

9 Sprint Time Length Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product. Sprints are limited to one calendar month. When a Sprint s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a goal at least every calendar month. Sprints also limit risk to one calendar month of cost. Sprint Planning Meeting The work to be performed in the Sprint is planned at the Sprint Planning Meeting. This plan is created by the collaborative work of the entire Scrum Team. The Sprint Planning Meeting is time-boxed to eight hours for a onemonth Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings. The Sprint Planning Meeting consists of two parts, each one being a time-box of one half of the Sprint Planning Meeting duration. The two parts of the Sprint Planning Meeting answer the following questions, respectively: What will be delivered in the Increment resulting from the upcoming Sprint? How will the work needed to deliver the Increment be achieved? 9

10 Sprint What will be done/ delivered? In this part, the Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner presents ordered Product Backlog items to the Development Team and the entire Scrum Team collaborates on understanding the work of the Sprint. The inputs to this meeting: the Product Backlog the latest product Increment, projected capacity of the Development Team during the Sprint, past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint. Sprint How will the work be chosen? The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during the Sprint Planning Meeting for the Development Team to forecast what it believes it can do in the upcoming Sprint. Story Time As a xxx, I will be able to yyy Planning Poker, Fist of Five, (clothing sizes) Complexity vs time By the end of the Sprint Planning Meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment. 10

11 Daily Scrum / Stand Up Meeting The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, each Development Team member explains: What has been accomplished since the last meeting? What will be done before the next meeting? What obstacles are in the way? Why Daily Scrum? Transparency high visibility of progress and accountability Adaptation catch problems early and allow for rapid response / change THIS IS NOT A STATUS MEETING TO COLLECT INFORMATION. It is a meeting in which every team member make commitments to each other. 11

12 Sprint Review A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. This is an informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. Sprint Review (2) The Sprint Review includes the following elements: The Development Team demonstrates the work that it has Done and answers questions about the Increment; The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved; The Product Owner identifies what has been Done and what has not been Done ; The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date; and, The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings. 12

13 Sprint Retrospective The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning Meeting. The purpose of the Sprint Retrospective is to: 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; and, Create a plan for implementing improvements to the way the Scrum Team does its work. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of Done as appropriate. Scrum Artifacts Scrum s artifacts represent work or value in various ways that are useful in providing transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information needed to ensure Scrum Teams are successful in delivering a Done Increment. 3 Principal Artifacts Product Backlog Sprint Backlog Increments Monitoring Progress Release Burn down Product Burn down Story Points, not time (Information Radiators) 13

14 Information Radiator An information radiator is a large, highly visible display used by software development teams to track progress. The term was first coined by Alistair Cockburn, one of the judges for the Ultimate Wallboard contest, in his book as follows: An Information radiator is a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions." It is large and easily visible to the casual, interested observer It is understood at a glance It changes periodically, so that it is worth visiting It is easily kept up to date 27 Product Backlog The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, and estimate. A The Product Backlog evolves as the product and the environment in which it will be used evolves. Story points, not time ( important so I mention it again) 14

15 Product Backlog (2) The Product Backlog is often written in story format, and ordered by value, risk, priority, and necessity. Top-ordered Product Backlog items drive immediate development activities. The higher the order, the more a Product Backlog item has been considered, and the more consensus exists regarding it and its value. Higher ordered Product Backlog items are clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are fine-grained, having been decomposed ( stories) so that any one item can be Done within the Sprint time-box. Product Backlog items that can be Done by the Development Team within one Sprint are deemed ready or actionable for selection in a Sprint Planning Meeting. Sprint Backlog The 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. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality. The Sprint Backlog defines the work ( stories, tasks) the Development Team will perform to turn Product Backlog items into a Done Increment. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. 15

16 Monitoring Progress At any point in time in a Sprint, the total work remaining in the Sprint Backlog items can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum and projects the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress. Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest. Monitoring Progress (2) Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest. Terms / definitions Scope / Target Beware target fixation Velocity Efficiency Variance Efficiency / Effectiveness waterfall is efficient agility is effective Release Burn down/burn up Product Burn down/burn up 16

17 Burn Down A burn-down chart tracks how much work remains on your project and whether you ll hit your deadline. The vertical axis measures work done, and projects work remaining The horizontal axis marks your iterations After each iteration you mark your progress on the chart and you can project forward to see whether or not you ll hit your target end date (assuming no changes) Burn Down Chart 34 17

18 Burn Down Chart positive variance 35 Burn Down Chart negative variance 36 18

19 Burn Down Chart - Question What happens if complexity/task is added or a story/task is dropped? Scope has been changed. How do I indicate in the burn down? Modify initial scope of work so line is continuous? Negates planning and all tracking to date Stair step line to indicate change and notate? More accurate, but a tracking nightmare 37 Burn Down Chart - Example Scenario: Initial plan was 14 points. On day 3, a complexity was uncovered, and 2 additional points were added. On day 5, it was determined to drop the story ( return to backlog), and reduce 4 points. Burndown to date: Day BD/Hist BD/TBD Delta New TBD Day Day Day Day Day Day Use initial velocity 38 19

20 Burn Down Chart (changes) 39 Burn Down Chart (changes)? 40 20

21 Burn Up A burn-up chart tracks how much work is done. It shows more information than a burn-down chart because it also has a line showing how much work is in the project as whole (the scope as workload), and this can change. It tracks what has been done and what s remaining. More adaptable to change. Burn Up Chart 42 21

22 Burn Up Chart positive variance 43 Burn Up Chart 44 22

23 Burn Up Chart (change 1) 45 Burn Up Chart (change 2) 46 23

24 Definition of Done When the Product Backlog item or an Increment is described as Done, everyone must understand what Done means. Members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the Definition of Done for the Scrum Team and is used to assess when work is complete on the product Increment. The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning Meeting. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team s current Definition of Done. As Scrum Teams mature, it is expected that their Definition of Done will expand to include more stringent criteria for higher quality. Done DoD Dilemma DoD Dilema -Different DoD for different teams For development some code is considered done when it has been written, compiled, debugged, unit tested, checked-in in a common repository, integrated in a build, verified by a build verification tool and documented using an automatic documentation generator. For automation test cases are considered done when the corresponding automated testing scripts have been coded, unit tested and ran against a build. For quality engineering done means that the user stories received on a specific build have been tested by running testing cycles, encountered bugs have been reported using a bug tracking tool, fixes provided have been validated and the associated trackers have been closed. In consequence, test cycles include both manual and automated test case execution. For project managers done means that the sprint has ended and the user stories have been completed (not necessarily accepted by QE) and the schedule hours burned. Moreover, for managers done usually means that there s something anything that can be presented to the stakeholders in a demo. 24

25 Done DoD Dilemma (2) DoD Holes DevelopmentDoDis not enough because code was produced but not tested, at least not tested from the users perspective. Crucial tests like functionality, usability, performance, scalability and stress are still pending. Without passing all those tests, at least to a certain level, the product is simply not good enough for being shipped. A big temptation is to consider that in early stages of the product, the code is not required to pass all tests or there s no need to test it at all. This of course violates the very definition / concept of a potentially shippable product. Automation DoD is not good enough either, because it only covers code that has been written to test code, no bugs discovered, validated, retested or closed. It s very true that automated test cases save many man hours of manual testing, but it should only be used as a tool that helps Quality Engineers in their work and not as a milestone that if reached qualifies the product for release. Project Manager s DoD it s focused on metrics and high level information. The biggest risk for Project Managers is to look at the wrong metrics and try to put a product out of the door when it s not complete or stable enough. Avoiding biased perceptions that come from information collected from only one group of engineers in a team is the key for telling if the product is ready or not to go into production. Done A starting Definition Definition of Done Coming from a quality background, Quality Engineering DoD in my opinion, is the initial definition that contributes the most to the goal of having a potentially shippable product; the reason in simple, QE should be the last check point for telling if the implemented user stories are good enough for being considered as part of a potentially shippable product. Potential additions can include documentation to be provided is available and has been reviewed for technical accuracy. Another is that automated test cases have been checked for effectiveness and real contribution to bug detection and validation. 25

26 DoD -First Pass Done means that the user stories received on a specific build have been included andtested by running testing cycles, encountered bugs have been reported using a bug tracking tool, fixes provided have been validated and the associated trackers have been closed. In consequence, test cycles include both manual and automated test case execution. DOD - Summary It is evident that we need a DoD that can work for the whole team helping it to remain focused in the right direction and serving at the same time as a true enabler for the potentially shippable product concept. Start simple, and enhance as skills and capability of Team matures. 26

27 Scrum Summary Definition of Scrum (n): An empirical FRAMEWORK within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. A key principle of Scrum is its recognition that during a project, customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the group s ability to deliver quickly and respond to emerging requirements. But, it s a FRAMEWORK, not a total solution Design Unit vs Integration Additional components to complete for the total solution I m Done Thanks nealk@isosys.com 27

28 Background - Agile Manifesto The Agile Manifesto is based on twelve principles: [15] Customer satisfaction by early and continuous delivery of valuable software Welcome changing requirements, even in late development Working software is delivered frequently (weeks rather than months) Close, daily cooperation between business people and developers Projects are built around motivated individuals, who should be trusted Face-to-face conversation is the best form of communication (co-location) Working software is the principal measure of progress Sustainable development, able to maintain a constant pace Continuous attention to technical excellence and good design Simplicity the art of maximizing the amount of work not done is essential Best architectures, requirements, and designs emerge from self-organizing teams Regularly, the team reflects on how to become more effective, and adjusts accordingly 55 28