Scrum Reference Card ‘by Michael James and Luke Walter About Scrum A Management Framework Scrum is a management framework for incremental product Govelopment using one or more cross-functional, self-organizing teams ‘of about seven people each It provides a structure of roles, meetings, rules, and artifsets. Teams are responsible for ereating and adapting their processes within this framework. Scrum uses fixed-length iterations, called Sprints. Sprints are no more than go days long, preferably shorter. Seram teams try to build a potentially releasable (properly tested) product increment every Sprint. An Alternative to Waterfall Scrum’s incremental, iterative approach trades the traditional phases of "waterfall" development forthe ability to develop a subset of high-value features firs, incorporating feedback sooner. asoy gare aie wa delet Spa mpi tog er me OO OD OO come Or eration Detail Pipa Sram be a dlp ate bosch rt adaping dawn edited ine ‘The greatest potential benefit of Scrum is for complex work involving, knowledge eceation and collaboration, such as new product evelopment. Serum is usually associated with object-oriented software development. Its use has aso spread to the development of products such as semiconductors, mortgages, and wheelchairs Doing Scrum, or Pretending to Do Scrum? individuals, teams, and organizations. Many people claiming to do Serum modify the pars that require breaking through organizational impediments and end up robbing themselves of most ofthe benefits. Scrum Development Team + Cross-funetional et, includes members with testing skills, and ‘others not traditionally called developers: business analysts, ‘designers, domain experts, ete.) + Selforganizing / self managing, without externally assigned roles + Plans one Sprint ata time with the Product Owner + Has autonomy regarding how to develop the increment + Intensely collaborative + Most successful when located in one team room, particularly for the first fev Sprints + Most successful with long-term, full-time membership. Scrum moves ‘work toa flexible learning team and avoids moving people or splitting them between teams. + 623 members + Has a leadership role Product Owner + Single person responsible for maximizing the return on investment (ROD ofthe development effort + Responsible for product vision + Constantly re-prioritizes the Produet Backlog, adjusting any long ‘term expectations such as release plans + Final arbiter of requirements questions + Decides whether to release + Decides whether to continue development + Considers stakeholder interests + May contribute asa team member + Has a leadership role Scrum Master + Works with the organization to make Scrum possible + Ensures Serum is understood and enacted + Creates an environment conducive to team self-organization + Shields the team from external interference and distractions to keep itin group flow (aka. the zone) + Promotes improved engineering practioes + Has no management authority over the team + Helps resolve impediments + Has aleadership role‘Sprint Planning Meeting Dally Serum ‘Sprint vow Meeting a Spear Revrspecive os Pipers Sen fw Sprint Planning Meeting At the beginning ofeach Sprint, the Product Owner and team hold a Sprint Planning Meeting to negotiate which Product Backlog Items they ‘will attempt to convert to working produet during the Sprint. The Product Owner is responsible for declaring whieh items are the most ‘important to the business. The Development Team is responsible for selecting the amount of work they fee! they can implement without aceruing technical debt. The team “pulls” work from the Product Backlog tothe Sprint Backlog. ‘When teams are given complex work that has inherent uncertainty, they must work together to intuitively gauge how much work to pull into a Sprint, while learning from previous Sprints. Planning their hourly capacity and comparing their estimazes to actuals makes the team pretend to be precise and reduces ownership. Unless the work is truly predictable, they should diseard such practices within the frst few Sprints or avoid them altogether. ‘Until a team has learned how to complete a potentially releasable product increment each Sprint, it should reduce the amount of functionality it plans. Failure to change old habits leads to techaieal bt and eventual design death, as shown in Figure 1. If the top of the Product Backlog has not been refined, portion of the Planning meeting might be spent doing this. ‘Toward the end ofthe Sprint Planning Meeting, the team determines how it will accomplish the work. For example they may break the selected items into an initial list of Sprint Tasks. ‘The maximum allotted time (a.k.a. timebox) for planning a 30-day Sprint is eight hours, reduced proportionally fr a shorter Sprint. Product Backlog Sprint Backlog > igure Sie Panny Mey otc some Prods Belo ons 5 and bie Set es Daily Scrum and Sprint Execution Every day atthe same time and place, the Serum Development Team members spend a total of 15 minutes inspecting their progress toward the Sprint goal, and creating a plan for the day, Team members share ‘with each other what they did the previous day to help meet the Sprint ‘308, what they'll do today, and what impediments they face. ‘Standing up at the Daily Serum will help keep it shor, Topies that ‘require additional attention may be discussed by whoever is interested after every team member has reported, ‘The team may find it useful to maintain a current Sprint Task List, and Sprint Burndown Chart. During Sprint exceution itis common to discover addtional tasks necessary to achieve the Sprint goals. Impediments caused by issues beyond the team’s control are considered organizational impediments ‘The Daly Serum is intended to disrupt old habits of working separately. Members should remain vigilant fr signs ofthe old approach, For example, looking only at the Serum Master when speaking is one symptom thatthe team hasn't learned to operate as & selForganizing entity. Sprint Review Meeting At the end ofthe Sprint, the Serum Team hokds a Sprint Review ‘Meeting to demoastrate a working product inerement to everyone who is interested, particularly outside stakeholders. ‘The meeting should feature a ive demonstration, nota report. ‘The Product Owner reviows the items selected during the Sprint Planning Meeting and explains which items are considered done. For ‘example, a software item that is merely “cade complete" is considered rot done, because untested software isn’t shippable. Incomplete items are returned to the Product Backlog and ranked according to the Produet Owners revised priorities as eandidates for future Sprints, “The Scrum Master helps the Product Owner and stakeholders convert their feedback to new Product Backlog Items for prioritization by the Produet Owner. Often, new scope discovery outpaces the team’s rate of development. Ifthe Product Owner fees that the newly discovered scope is more important than the original expectations, new seope displaces old scope in the Product Backlog. Some items will never be done. “The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend, Its the opportunity to inspect land adapt the product as it emerges. New products, particularly software produits, are hard to visualize in a vacuum. Many customers ‘need to beable to react to a piece of functioning software to discover ‘what they will actually want. erative development, a value-driven approach, allows the creation of products that coulda’t have been specified up front in a plan-driven approach,Sprint Retrospective Mecting Lach Sprint ends with a retrospective. At this meeting. the team reflects ‘utils wu prowess. They iuepeet ver belasiveand take action to adapt {for fom Spins Dodlented Semim Masters will find altemarlvesto the stale, feasful meetings everyone has come to expect. An in-depth retrospective requires an environment of payehological safety not found in most ‘organirations. Without safety, the retrospective discussion wil either avoid Unv uueoulortable issue or Ueterivrae into blaming and. Trost. ‘Nemmon impestiment ra fol rmnaparency an the team is the presence ‘of people who conduct performance appraisals. Another impediment to an insishtful retrospective isthe human lendeney to jump to conclusions an propose actions too quickly. Agile etrospecrives, the mast popiiar hook on this top, describes a series, ‘lsteps (oslo tis prowess down, Se Une slaw, gather data, zenerate incight,deide what rod, loan the retrogpective. Another zuide recommended for Scrum Masters, Yhe Art of Focused Conversations. bres le proces in sila steps: Objective reflective, interpretive, andl decisional (ORI) = third impediment to psyrhfogieal cafety is gangraphiedstibtion Geographically dispersed teams usualy do not collaborate as well as those in team rooms. Retrospectives often expose organizational impediments. Once a team hhas resolved the impediments within its immediate inuence, the Serum Master should work to expand that influence, chipping away at ‘the organizational impediments Scrum Masters should usea variety of techniques to facilitate retrospectives, including silent writing, timelines, and satisfaction histograms. In all cases, the goals are to gain a common understanding ‘of multiple perspectives and to develop actions that will take the team and organization tothe neat level Backlog Refinement Meeting ‘Most Product Backlog Items (PBIs) intially need refinement because they are too large and poorly understood. While Backlog Refinement is nota required event, itis a required activity. Most Scrum Teams find it ‘useful to take a short time out of every Sprint for this activity. They get together to prepare the Product Backlog for upcoming Sprint Planning ‘Meetings. In the Backlog Refinement Meeting, lage vague items are split and clarified, considering both business and technical concerns. Sometimes a subset of the team, in conjunction with the Produet Owner and other stakeholders, will eompose and spit Product Backlog Items before invelving the entire eam. While refining items, the team may estimate the amount of effort they would expend to complete items in Uw Product Baeklox and provides ‘other technical information to ep the Pradiiet Oumer priortie them, A lied Serum Master ean help the team i@emtify thin vertical slices of ‘york thal sll ave business value, lute promoting.a rigorous {finition of one" that inehdes proper testing and refactoring. It is eomman ta unite Prndnet Raekag Tom int this approach, oversized I'lls are called epics. Tr Dorel ealure inlo horizontal tate (resembling waterfall phases) that cannot be pririiend independently nd le: hasiness value from the ‘customers petspecive, This habits hard to break Ally nequtes Learning to split lar epis into user stories representing very small product fentures. For example, in a medical ecards application the epic “display the entire sontents ofa patient's “Ai Rete, Pa Bel Dethy/Lan 8) Mh if Noe Ben Pats ‘he eam socal pad t-te mE * verso Ame for ap soar etapa. don ee, Cin (2008) allergy records toa doctor" yielded the story “display whether or not any allergy records exist.” While the engineers anticipated significant technical challenges in parcing the internal aepocte ofthe allergy records the presence or absence of any allergy was the most important thing the doctors needed to know. Collaboration between business people and technical people to split this epie yielded a story ‘representing 80% of the business value for 20% of the effort of the original epic. ince most customers don't use mast features of most products, i's ice to anit epics to deliver the most valuable stores first. While dtvering lower alu features ate key to ivole some rework, ‘This activity has also been called “Backlog Grooming,"“Backlog Maintenance,” oF “Story Time.” igure ein cig Refer arg Ps fe cae "ys arte pa he Prd ‘Bak oan cote fa es Car nt hora epleneton pase ‘Scrum defines three artifaets: Product Backlog, Sprint Backlog, and Increment, Product Backlog oly one item atatime topttems is top priority pranular ee Pr ‘TMforee ranked (prioritized) Bit of desired functionality Visible to all etakehalders + Anystakeholder (including the Team) can add items + Constantly re-prioritized by the Product Owner + Coustantly refined by the Seruiu Teaus + Hemet tp shoul be smaller (eg. smaller than 1/4 of Sprint) than items at bottom