Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,535
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
193
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. February 2010Scrum: Developed and sustained by Ken Schwaber and Jeff Sutherland
  • 2. AcknowledgementsGeneralScrum is based on industry-accepted best practices, used and provenfor decades. It is then set in an empirical process theory. As JimCoplien once remarked to Jeff, “Everyone will like Scrum; it is what wealready do when our back is against the wall.”PeopleOf the thousands of people that have contributed to Scrum, we shouldsingle out those that were instrumental in its first ten years. First therewere Jeff Sutherland, working with Jeff McKenna, and Ken Schwaberwith Mike Smith and Chris Martin. Scrum was first formally presentedand published at OOPSLA 1995. During the next five years, MikeBeedle and Martine Devos made significant contributions. And theneveryone else, without whose help Scrum wouldn’t have been refinedinto what it is today.HistoryThe history of Scrum can already be considered long in the world ofsoftware development. To honor the first places where it was tried andrefined, we honor Individual, Inc., Fidelity Investments, and IDX (nowGE Medical).© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 2
  • 3. PurposeScrum has been used to develop complex products since the early1990s. This paper describes how to use Scrum to build products.Scrum is not a process or a technique for building products; rather, itis a framework within which you can employ various processes andtechniques. The role of Scrum is to surface the relative efficacy of yourdevelopment practices so that you can improve upon them whileproviding a framework within which complex products can bedeveloped.Scrum TheoryScrum, which is grounded in empirical process control theory, employsan iterative, incremental approach to optimize predictability andcontrol risk. Three pillars uphold every implementation of empiricalprocess control.The first leg is transparencyTransparency ensures that aspects of the process that affect theoutcome must be visible to those managing the outcomes. Not onlymust these aspects be transparent, but also what is being seen mustbe known. That is, when someone inspecting a process believes thatsomething is done; it must be equivalent to their definition of done.The second leg is inspectionThe various aspects of the process must be inspected frequentlyenough so that unacceptable variances in the process can be detected.The frequency of inspection has to take into consideration that allprocesses are changed by the act of inspection. A conundrum occurswhen the required frequency of inspection exceeds the tolerance toinspection of the process. Fortunately, this doesn’t seem to be true ofsoftware development. The other factor is the skill and diligence of thepeople inspecting the work results.© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 3
  • 4. The third leg is adaptationIf the inspector determines from the inspection that one or moreaspects of the process are outside acceptable limits, and that theresulting product will be unacceptable, the inspector must adjust theprocess or the material being processed. The adjustment must bemade as quickly as possible to minimize further deviation.There are three points for inspection and adaptation in Scrum. TheDaily Scrum meeting is used to inspect progress toward the Sprintgoal, and to make adaptations that optimize the value of the nextwork day. In addition, the Sprint Review and Planning meetings areused to inspect progress toward the Release Goal and to makeadaptations that optimize the value of the next Sprint. Finally, theSprint Retrospective is used to review the past Sprint and determinewhat adaptations will make the next Sprint more productive, fulfilling,and enjoyable.Scrum ContentThe Scrum framework consists of a set of Scrum Teams and theirassociated roles; Time-Boxes, Artifacts, and Rules.Scrum Teams are designed to optimize flexibility and productivity; tothis end, they are self-organizing, they are cross-functional, and theywork in iterations. Each Scrum Team has three roles: 1) theScrumMaster, who is responsible for ensuring the process isunderstood and followed; 2) the Product Owner, who is responsiblefor maximizing the value of the work that the Scrum Team does; and3) the Team, which does the work. The Team consists of developerswith all the skills to turn the Product Owner’s requirements into apotentially releasable piece of the product by the end of the Sprint.Scrum employs time boxes to create regularity. Elements of Scrumthat are time-boxed include the Release Planning Meeting, theSprint Planning Meeting, the Sprint, the Daily Scrum, the SprintReview, and the Sprint Retrospective. The heart of Scrum is aSprint, which is an iteration of one month or less that is of consistent© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 4
  • 5. length throughout a development effort. All Sprints use the sameScrum framework, and all Sprints deliver an increment of the finalproduct that is potentially releasable. One Sprint starts immediatelyafter the other.Scrum employs four principal artifacts. The Product Backlog is aprioritized list of everything that might be needed in the product. TheSprint Backlog is a list of tasks to turn the Product Backlog for oneSprint into an increment of potentially shippable product. A burndownis a measure of remaining backlog over time. A Release Burndownmeasures remaining Product Backlog across the time of a release plan.A Sprint Burndown measures remaining Sprint Backlog itemsacross the time of a Sprint.Rules bind together Scrum’stime-boxes, roles, and artifacts. TipIts rules are described throughout When rules are not stated, thethe body of this document. For users of Scrum are expectedexample, it is a Scrum rule that to figure out what to do. Don’tonly Team members - the people try to figure out a perfect solution, because the problemcommitted to turning the Product usually changes quickly.Backlog into an increment – can Instead, try something andtalk during a Daily Scrum. Ways of see how it works. The inspect- and-adapt mechanisms ofimplementing Scrum that are not Scrum’s empirical nature willrules but rather are suggestions guide you.are described in “Tips” boxes.Scrum RolesThe Scrum Team consists of the ScrumMaster, the Product Owner, andthe Team. Scrum Team members are called “pigs.” The ProductOwner is the “pig” of the Product Backlog. The Team is the “pig” ofthe Sprint work. The ScrumMaster is the “pig” of the Scrum process.Everyone else is a “chicken.” Chickens cannot tell “pigs” how to dotheir work. Chickens and pigs come from the story,© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 5
  • 6. “A chicken and a pig are together when the chicken says, "Lets start a restaurant!" The pig thinks it over and says, "What would we call this restaurant?" The chicken says, "Ham n Eggs!" The pig says, "No thanks, Id be committed, but youd only be involved!" Tip The ScrumMaster works withThe ScrumMaster the customers and management to identify andThe ScrumMaster is responsible for instantiate a Product Owner.ensuring that the Scrum Team The ScrumMaster teachesadheres to Scrum values, practices, the Product Owner how to do his or her job. Productand rules. The ScrumMaster helps Owners are expected tothe Scrum Team and the know how to manage to optimize value using Scrum.organization adopt Scrum. The If they don’t, we hold theScrumMaster teaches the Scrum ScrumMaster accountable.Team by coaching and by leading itto be more productive and producehigher quality products. TheScrumMaster helps the Scrum Team Tipunderstand and use self- The ScrumMaster may be a member of the Team; fororganization and cross- example, a developerfunctionality. The ScrumMaster also performing Sprint tasks.helps the Scrum Team do its best in However, this often leads to conflicts when thean organizational environment that ScrumMaster has to choosemay not yet be optimized for between removingcomplex product development. impediments and performing tasks. The ScrumMasterWhen the ScrumMaster helps make should never be the Productthese changes, this is called Owner.“removing impediments.” TheScrumMaster’s role is one of aservant-leader for the Scrum Team.© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 6
  • 7. The Product OwnerThe Product Owner is the oneand only person responsible for Tipmanaging the Product Backlog For commercial development,and ensuring the value of the the Product Owner may be thework the Team performs. This product manager. For in-house development efforts, theperson maintains the Product Product Owner could be theBacklog and ensures that it is manager of the businessvisible to everyone. Everyone function that is being automated.knows what items have thehighest priority, so everyoneknows what will be worked on.The Product Owner is oneperson, not a committee. TipCommittees may exist that The Product Owner can be a Team member, also doingadvise or influence this person, development work. Thisbut people who want to change additional responsibility mayan item’s priority have to cut into the Product Owner’s ability to work withconvince the Product Owner. stakeholders. However, theCompanies that adopt Scrum Product Owner can never be the ScrumMaster.may find it influences theirmethods for setting priorities andrequirements over time.For the Product Owner to succeed, everyone in the organization has torespect his or her decisions. No one is allowed to tell the Team to workfrom a different set of priorities, and Teams aren’t allowed to listen toanyone who says otherwise. The Product Owner’s decisions are visiblein the content and prioritization of the Product Backlog. This visibilityrequires the Product Owner to do his or her best, and it makes the roleof Product Owner both a demanding and a rewarding one.© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 7
  • 8. The TeamTeams of developers turn Product Backlog into increments ofpotentially shippable functionality every Sprint. Teams are also cross-functional; Team members must have all of the skills necessary tocreate an increment of work. Team members often have specializedskills, such as programming, quality control, business analysis,architecture, user interface design, or data base design. However, theskills that Team member share – that is, the skill of addressing arequirement and turning it into a usable product – tend to be moreimportant than the ones that they do not. People who refuse to codebecause they are architects or designers are not good fits for Teams.Everyone chips in, even if that requires learning new skills orremembering old ones. There are no titles on Teams, and there are noexceptions to this rule. Teams do not contain sub-Teams dedicated toparticular domains like testing or business analysis, either.Teams are also self-organizing. No one – not even the ScrumMaster -tells the Team how to turn Product Backlog into increments ofshippable functionality. The Team figures this out on its own. EachTeam member applies his or her expertise to all of the problems. Thesynergy that results improves the entire Team’s overall efficiency andeffectiveness.The optimal size for a Team is seven people, plus or minus two. Whenthere are fewer than five Team members, there is less interaction andas a result less productivity gain. What’s more, the Team mayencounter skill constraints during parts of the Sprint and be unable todeliver a releasable piece of the product. If there are more than ninemembers, there is simply too much coordination required. LargeTeams generate too much complexity for an empirical process tomanage. However, we have encountered some successful Teams thathave exceeded the upper and lower bounds of this size range. TheProduct Owner and ScrumMaster roles are not included in this countunless they are also pigs, working on tasks in the Sprint Backlog.© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 8
  • 9. Team composition may change at the end of a Sprint. Every timeTeam membership is changed, the productivity gained from self-organization is diminished. Care should be taken when changing Teamcomposition.Time-BoxesThe Time-Boxes in Scrum are the Release Planning Meeting, theSprint, the Sprint Planning Meeting, the Sprint Review, theSprint Retrospective, and the Daily Scrum.Release Planning MeetingThe purpose of release planning is to establish a plan and goals thatthe Scrum Teams and the rest of the organizations can understandand communicate. Release planning answers the questions, “How canwe turn the vision into a winning product in best possible way? Howcan we meet or exceed the desired customer satisfaction and Returnon Investment?” The release plan establishes the goal of the release,the highest priority Product Backlog, the major risks, and the overallfeatures and functionality that the release will contain. It alsoestablishes a probable delivery date and cost that should hold ifnothing changes. The organization can then inspect progress andmake changes to this release plan on a Sprint-by-Sprint basis.Release planning is entirely optional. If Scrum teams start workwithout the meeting, the absence of its artifacts will become apparentas an impediment that needs to be resolved. Work to resolve theimpediment will become an item in the Product Backlog.Products are built iteratively using Scrum, wherein each Sprint createsan increment of the product, starting with the most valuable andriskiest. More and more Sprints create additional increments of theproduct. Each increment is a potentially shippable slice of the entireproduct. When enough increments have been created for the Productto be of value, of use to its investors, the product is released.© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 9
  • 10. Most organizations already have a release planning process, and inmost of these processes most of the planning is done at the beginningof the release and left unchanged as time passes. In Scrum releaseplanning, an overall goal and probable outcomes are defined. Thisrelease planning usually requires no more than 15-20% of the time anorganization consumed to build a traditional release plan. However, aScrum release performs just-in-time planning every Sprint Review andSprint Planning meeting, as well as daily just-in-time planning at everyDaily Scrum meeting. Overall, Scrum release efforts probably consumeslightly more effort than tradition release planning efforts.Release planning requires estimating and prioritizing the ProductBacklog for the Release. There are many techniques for doing so thatlie outside the purview of Scrum but are nonetheless useful when usedwith it.The SprintA Sprint is an iteration. Sprintsare time-boxed. During the TipSprint, the ScrumMaster ensures If the Team senses that it hasthat no changes are made that overcommitted, it meets with the Product Owner to removewould affect the Sprint Goal. or reduce the scope of ProductBoth Team composition and Backlog selected for the Sprint.quality goals remain constant If the Team senses that it may have extra time, it can workthroughout the Sprint. Sprints with the Product Owner tocontain and consist of the Sprint select additional ProductPlanning meeting, the Backlog.development work, the SprintReview, and the Sprint Retrospective. Sprints occur one after another,with no time in between Sprints.A project is used to accomplish something; in software development, itis used to build a product or system. Every project consists of adefinition of what is to be built, a plan to build it, the work doneaccording to the plan, and the resultant product. Every project has ahorizon, which is to say the time frame for which the plan is good. If© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 10
  • 11. the horizon is too long, thedefinition may have changed, too Tipmany variables may have When a Team begins Scrum,entered in, the risk may be too two-week Sprints allow it to learn without wallowing ingreat, etc. Scrum is a framework uncertainty. Sprints of thisfor a project whose horizon is no length can be synchronized with other Teams by adding twomore than one month long, increments together.where there is enoughcomplexity that a longer horizonis too risky. The predictability of the project has to be controlled atleast each month, and the risk that the project may go out of controlor become unpredictable is contained at least each month.Sprints can be cancelled before the Sprint time box is over. Only theProduct Owner has the authority to cancel the Sprint, although he orshe may do so under influence from the stakeholders, the Team, orthe ScrumMaster. Under what kind of circumstances might a Sprintneed to be cancelled? Management may need to cancel a Sprint if theSprint Goal becomes obsolete. This could occur if the companychanges direction or if market or technology conditions change. Ingeneral, a Sprint should be cancelled if it no longer makes sense giventhe circumstances. However, because of the short duration of Sprints,it rarely makes sense to do so.When a Sprint is cancelled, any completed and “done” Product Backlogitems are reviewed. They are accepted if they represent a potentiallyshippable increment. All other Product Backlog items are put back onthe Product Backlog with their initial estimates. Any work done onthem is assumed to be lost. Sprint terminations consume resources,since everyone has to regroup in another Sprint planning meeting tostart another Sprint. Sprint terminations are often traumatic to theTeam, and they are very uncommon.Sprint Planning MeetingThe Sprint Planning meeting is when the iteration is planned. It istime-boxed to eight hours for a one month Sprint. For shorter Sprints,© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 11
  • 12. allocate proportionately less of the total Sprint length to this meeting(for example, two weeks would be a four-hour Sprint PlanningMeeting). The Sprint Planning Meeting consists of two parts. The firstpart is when what will be done in the Sprint is decided upon. Thesecond part (a four-hour time-box for a monthly Sprint) is when theTeam figures out how it is going to build this functionality into aproduct increment during the Sprint.There are two parts to the Sprint Planning Meeting: the “What?” partand the “How?” part. Some Scrum Teams combine the two. In the firstpart, the Scrum Team addresses the question of “What?” Here, theProduct Owner presents the top priority Product Backlog to the Team.They work together to figure out what functionality is to be developedduring the next Sprint. The input to this meeting is the ProductBacklog, the latest increment of product, the capacity of the Team,and past performance of the Team. The amount of backlog the Teamselects is solely up to the Team. Only the Team can assess what it canaccomplish over the upcoming Sprint.Having selected the Product Backlog, a Sprint Goal is crafted. TheSprint Goal is an objective that will be met through the implementationof the Product Backlog. This is a statement that provides guidance tothe Team on why it is building the increment. The Sprint Goal is asubset of the release goal.The reason for having a Sprint Goal is to give the Team some wiggleroom regarding the functionality. For example, the goal for the aboveSprint could also be: “Automate the client account modificationfunctionality through a secure, recoverable transaction middlewarecapability.” As the Team works, it keeps this goal in mind. In order tosatisfy the goal, it implements the functionality and technology. If thework turns out to be harder than the Team had expected, then theTeam collaborates with the Product Owner and only partiallyimplement the functionality.© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 12
  • 13. In the second part of the Sprint Planning Meeting, the Team addressesthe question of “How?” During the second part of the Sprint PlanningMeeting (four hour time-box for a monthly Sprint), the Team figuresout how it will turn the Product Backlog selected during Sprint PlanningMeeting (What) into a done increment. The Team usually starts bydesigning the work. While designing, the Team identifies tasks. Thesetasks are the detailed pieces of work needed to convert the ProductBacklog into working software. Tasks should have decomposed so theycan be done in less than one day. This task list is called the SprintBacklog. The Team self-organizes to undertake the work in the SprintBacklog, either during the Sprint Planning meeting or just-in-timeduring the Sprint.The Product Owner is present during the second part of the SprintPlanning Meeting to clarify theProduct Backlog and to helpmake trade-offs. If the Team Tipdetermines that it has too much Usually, only 60-70% of theor too little work, it may total Sprint Backlog will be devised in the Sprint Planningrenegotiate the Product Backlog meeting. The rest is stubbedwith the Product Owner. The out for later detailing, or given large estimates that will beTeam may also invite other decomposed later in the Sprint.people to attend in order toprovide technical or domainadvice. A new Team often first realizes that it will either sink or swimas a Team, not individually, in this meeting. The Team realizes that itmust rely on itself. As it realizes this, it starts to self-organize to takeon the characteristics and behavior of a real Team.Sprint ReviewAt the end of the Sprint, a Sprint Review meeting is held. This is a fourhour time-boxed meeting for one month Sprints. For Sprints of lesserduration, allocate proportionately less of the total Sprint length to thismeeting (for example, two weeks would be a two-hour Sprint Review).During the Sprint Review, the Scrum Team and stakeholders© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 13
  • 14. collaborate about what was just done. Based on that and changes tothe Product Backlog during the Sprint, they collaborate about what arethe next things that could be done. This is an informal meeting, withthe presentation of the functionality intended to foster collaborationabout what to do next.The meeting includes at least the following elements. The ProductOwner identifies what has been done and what hasn’t been done. TheTeam discusses what went well during the Sprint and what problems itran into, and how it solved these problems. The Team thendemonstrates the work that is done and answers questions. TheProduct Owner then discusses the Product Backlog as it stands. He orshe projects likely completion dates with various velocity assumptions.The entire group then collaborates about what it has seen and whatthis means regarding what to do next. The Sprint Review providesvaluable input to subsequent Sprint Planning meeting.Sprint RetrospectiveAfter the Sprint Review and prior to the next Sprint Planning meeting,the Scrum Team has a Sprint Retrospective meeting. This is a threehour, time-boxed meeting for monthly Sprints (allocate proportionatelyless of the total Sprint length to this meeting). At this meeting, theScrumMaster encourages the Scrum Team to revise, within the Scrumprocess framework and practices, its development process to make itmore effective and enjoyable for the next Sprint. Many booksdocument techniques that are helpful to use in Retrospectives.The purpose of the Retrospective is to inspect how the last Sprint wentin regards to people, relationships, process and tools. The inspectionshould identify and prioritize the major items that went well and thoseitems that-if done differently-could make things even better. Theseinclude Scrum Team composition, meeting arrangements, tools,definition of “done,” methods of communication, and processes forturning Product Backlog items into something “done.” By the end ofthe Sprint Retrospective, the Scrum Team should have identifiedactionable improvement measures that it implements in the next© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 14
  • 15. Sprint. These changes become the adaptation to the empiricalinspection.Daily ScrumEach Team meets daily for a 15-minute inspect and adapt meetingcalled the Daily Scrum. The Daily Scrum is at the same time and sameplace throughout the Sprints. During the meeting, each Team memberexplains: 1. What he or she has accomplished since the last meeting; 2. What he or she is going to do before the next meeting; and 3. What obstacles are in his or her way.Daily Scrums improve communications, eliminate other meetings,identify and remove impediments to development, highlight andpromote quick decision-making, and improve everyones level ofproject knowledge.The ScrumMaster ensures that the Team has the meeting. The Team isresponsible for conducting the Daily Scrum. The ScrumMaster teachesthe Team to keep the Daily Scrum short by enforcing the rules andmaking sure that people speak briefly. The ScrumMaster also enforcesthe rule that chickens are not allowed to talk or in anyway interferewith the Daily Scrum.The Daily Scrum is not a status meeting. It is not for anyone but thepeople transforming the Product Backlog items into an increment (theTeam). The Team has committed to a Sprint Goal, and to theseProduct Backlog items. The Daily Scrum is an inspection of theprogress toward that Sprint Goal (the three questions). Follow-onmeetings usually occur to make adaptations to the upcoming work inthe Sprint. The intent is to optimize the probability that the Team willmeet its Goal. This is a key inspect and adapt meeting in the Scrumempirical process.© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 15
  • 16. Scrum ArtifactsScrum Artifacts include the Product Backlog, the Release Burndown,the Sprint Backlog, and the Sprint Burndown.Product Backlog and Release BurndownThe requirements for the product that the Team(s) is developing arelisted in the Product Backlog. The Product Owner is responsible for theProduct Backlog, its contents, its availability, and its prioritization.Product Backlog is never complete. The initial cut at developing it onlylays out the initially known and best-understood requirements. TheProduct Backlog evolves as the product and the environment in whichit will be used evolves. The Backlog is dynamic in that it constantlychanges to identify what the product needs to be appropriate,competitive, and useful. As long as a product exists, Product Backlogalso exists.The Product Backlog represents Tipeverything necessary to develop Product Backlog items areand launch a successful product. usually stated as User Stories.It is a list of all features, Use Cases are appropriate asfunctions, technologies, well, but they are better for use in developing life- or mission-enhancements, and bug fixes critical software.that constitute the changes thatwill be made to the product forfuture releases. Product Backlog items have the attributes of adescription, priority, and estimate. Priority is driven by risk, value, andnecessity. There are many techniques for assessing these attributes.Product Backlog is sorted in order of priority. Top priority ProductBacklog drives immediate development activities. The higher thepriority, the more urgent it is, the more it has been thought about, andthe more consensus there is regarding its value. Higher prioritybacklog is clearer and has more detailed information than lowerpriority backlog. Better estimates are made based on the greater© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 16
  • 17. clarity and increased detail. Thelower the priority, the less the Tipdetail, until you can barely make Scrum Teams often spend 10% of each Sprint grooming theout the item. product backlog to meet the above definition of the ProductAs a product is used, as its value Backlog. When groomed to thisincreases, and as the level of granularity, the Product Backlog items at the top of themarketplace provides feedback, Product Backlog (highestthe product’s backlog emerges priority, greatest value) areinto a larger and more decomposed so they fit within one Sprint. They have beenexhaustive list. Requirements analyzed and thought throughnever stop changing. Product during the grooming process.Backlog is a living document. When the Sprint Planning meeting occurs, these topChanges in business priority Product Backlog itemsrequirements, market conditions, are well understood and easily selected.technology, and staffing causechanges in the Product Backlog.To minimize rework, only thehighest priority items need to be Tipdetailed out. The Product Backlog Acceptance tests are often useditems that will occupy the Teams as another Product Backlogfor the upcoming several Sprints item attribute. They can often supplant more detailed textare fine-grained, having been descriptions with a testabledecomposed so that any one description of what the Productitem can be done within the Backlog item must do when completed.duration of the Sprint.Multiple Scrum Teams often work together on the same product. OneProduct Backlog is used to describe the upcoming work on the Product.A Product Backlog attribute that groups items is then employed.Grouping can occur by feature set, technology, or architecture, and itis often used as a way to organize work by Scrum Team.The Release Burndown graph records the sum of remaining ProductBacklog estimated effort across time. The estimated effort is in© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 17
  • 18. whatever unit of work the ScrumTeam and organization have Tipdecided upon. The units of time In some organizations, more work is added to the backlogare usually Sprints. than is completed. This may create a trend line that is flat orProduct Backlog item estimates even slopes upwards. Toare calculated initially during compensate for this and retain transparency, a new floor mayRelease Planning, and thereafter be created when work is addedas they are created. During or subtracted. The floor shouldProduct Backlog grooming they add or remove only significant changes and should be wellare reviewed and revised. documented.However, they can be updated atany time. The Team isresponsible for all estimates. TheProduct Owner may influence the TipTeam by helping understand and The trend line may beselect trade-offs, but the final unreliable for the first two toestimate is made by the Team. three Sprints of a releaseThe Product Owner keeps an unless the Teams have worked together before, know theupdated Product Backlog list product well, and understandRelease Backlog Burndown the underlying technology.posted at all times. A trend linecan be drawn based on thechange in remaining work.Sprint Backlog and Sprint BurndownThe Sprint Backlog consists of the tasks the Team performs to turnProduct Backlog items into a “done” increment. Many are developedduring the Sprint Planning Meeting. It is all of the work that the Teamidentifies as necessary to meet the Sprint goal. Sprint Backlog itemsmust be decomposed. The decomposition is enough so changes inprogress can be understood in the Daily Scrum. One day or less is ausual size for a Sprint Backlog item that is being worked on.The Team modifies Sprint Backlog throughout the Sprint, as well asSprint Backlog emerging during the Sprint. As it gets into individual© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 18
  • 19. tasks, it may find out that more or fewer tasks are needed, or that agiven task will take more or less time than had been expected. As newwork is required, the Team adds it to the Sprint Backlog. As tasks areworked on or completed, the estimated remaining work for each taskis updated. When tasks are deemed unnecessary, they are removed.Only the Team can change its Sprint Backlog during a Sprint. Only theTeam can change the contents or the estimates. The Sprint Backlog isa highly visible, real time picture of the work that the Team plans toaccomplish during the Sprint, and it belongs solely to the Team.Sprint Backlog Burndown is a graph of the amount of Sprint Backlogwork remaining in a Sprint acrosstime in the Sprint. To create this Tipgraph, determine how muchwork remains by summing the Whenever possible, hand draw the burndown chart on a bigbacklog estimates every day of sheet of paper displayed in thethe Sprint. The amount of work Teams work area. Teams are more likely to see a big, visibleremaining for a Sprint is the sum chart than they are to look atof the work remaining for all of Sprint burndown chart in ExcelSprint Backlog. Keep track of or a tool.these sums by day and use themto create a graph that shows the work remaining over time. Bydrawing a line through the points on the graph, the Team can manageits progress in completing a Sprint’s work. Duration is not consideredin Scrum. Work remaining and date are the only variables of interest.One of Scrums rules pertains to the purpose of each Sprint, which isto deliver increments of potentially shippable functionality that adheresto a working definition of “done.”© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 19
  • 20. DoneScrum requires Teams to build an increment of product functionalityevery Sprint. This increment must be potentially shippable, for ProductOwner may choose to immediately implement the functionality. To doso, the increment must be a complete slice of the product. It must be“done.” Each increment should be additive to all prior increments andthoroughly tested, ensuring that all increments work together.In product development, asserting that functionality is done might leadsomeone to assume that it is at least cleanly coded, refactored, unittested, built, and acceptance tested. Someone else might assume onlythat the code has been built. If everyone doesn’t know what thedefinition of “done” is, the other two legs of empirical process controldon’t work. When someone describes something as done, everyonemust understand what done means.Done defines what the Team means when it commits to “doing” aProduct Backlog item in a Sprint. Some products do not containdocumentation, so the definition of “done” does not includedocumentation. A completely “done” increment includes all of theanalysis, design, refactoring, programming, documentation and testingfor the increment and all Product Backlog items in the increment.Testing includes unit, system, user, and regression testing, as well asnon-functional tests such asperformance, stability, security,and integration. Done includes Tipany internationalization. Some “Undone” work is often accumulated in a ProductTeams aren’t yet able to include Backlog item called “Undoneeverything required for Work” or “Implementationimplementation in their definition Work.” As this work accumulates, the Productof done. This must be clear to Backlog burndown remainsthe Product Owner. This more accurate than if it weren’tremaining work will have to be accumulated.done before the product can beimplemented and used.© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 20
  • 21. FINAL THOUGHTSSome organizations are incapable of building a complete incrementwithin one Sprint. They may not yet have the automated testinginfrastructure to complete all of the testing. In this case, twocategories are created for each increment: the “done” work and the“undone” work. The “undone” work is the portion of each incrementthat will have to be completed at a later time. The Product Ownerknows exactly what he or she is inspecting at the end of the Sprintbecause the increment meets the definition of “done” and the ProductOwner understands the definition. “Undone” work is added to aProduct Backlog item named “undone work” so it accumulates andcorrectly reflects on the Release Burndown graph. This techniquecreates transparency in progress toward a release. The inspect andadapt in the Sprint Review is as accurate as this transparency.For instance, if a Team is not able to do performance, regression,stability, security, and integration testing for each Product Backlogitem, the proportion of this work to the work that can be done(analysis, design, refactoring, programming, documentation, unit anduser testing) is calculated. Let’s say that this proportion is six pieces of“done” and four pieces on “undone.” If the Team finishes a ProductBacklog item of six units of work (the Team is estimating based onwhat it knows how to “do”), four is added to the “undone work”Product Backlog item when they are finished.Sprint by Sprint, the “undone” work of each increment is accumulatedand must be addressed prior to releasing the product. This work isaccumulated linearly although it actually has some sort of exponentialaccumulation that is dependent on each organization’s characteristics.Release Sprints are added to the end of any release to complete this“undone” work. The number of Sprints is unpredictable to the degreethat the accumulation of “undone” work is not linear.© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 21