Scrum:aBreathtakinglyBriefandAgile

Introduction

Thisoverviewofroles,artifactsandthesprintcycleisadaptedfrom

TheElementsofScrumbyChrisSims&HillaryLouiseJohnson

Scrum:aBreathtakinglyBrief

andAgileIntroduction

©2012ChrisSims&HillaryLouiseJohnson

ISBN#978-1-937965-04-4

PublishedbyDymaxicon

AnImprintofAgileLearningLabs

MaterialinthisbookhasbeenadaptedfromTheElementsofScrumbyChrisSims&Hillary

LouiseJohnson

TableofContents

WhatisScrum?

Roles

ProductOwner

ScrumMaster

TeamMember

ScrumArtifacts

TheProductBacklog

TheSprintBacklog

BurnCharts

TaskBoard

DefinitionofDone

TheSprintCycle

It’saboutrhythm

SprintPlanningMeeting

DailyScrum

StoryTime

SprintReview

Retrospective

AbnormalSprintTermination(WhenGoodSprintsGoBad)

Inspect&Adapt,Baby!

Appendix:Values&Principles

Ifyouenjoyedthistitle...

WhatisScrum?Scrumisa lightweight frameworkdesignedtohelpsmall,close-knit teamsofpeopledevelopcomplexproducts.Thebrainchildofahandfulofsoftwareengineersworkingtogetherinthelate 20thCentury, scrumhasgained themost traction in the technology sector, but it isnotinherentlytechnicalandyoucaneasilyadaptthetoolsandpracticesdescribedinthisbooktoother industries. You canuse scrum to build a bettermousetrap, for example, or to run themarketingdivisionofapuppychowcompany.Youcanevenuseittocollaborateonwritingabook—wedid.A scrum team typically consists of around seven people who work together in short,

sustainableburstsofactivitycalledsprints,withplentyoftimeforreviewandreflectionbuiltin.Oneofthemantrasofscrumis“inspectandadapt,”andscrumteamsarecharacterizedbyanintensefocusoncontinuousimprovement—oftheirprocess,butalsooftheproduct.Thistinybookisajust-the-facts-ma’amintroductiontothevariousmovingpartsofscrum:the

variousroles,artifactsandeventsthatoccupythesprintcycle.

Roles

Scrumrecognizesonlythreedistinctroles:productowner,scrummaster,

andteammember

ProductOwner

Adevelopmentteamrepresentsasignificantinvestmentonthepartofthebusiness.Therearesalaries topay,offices torent,computersandsoftware to buy andmaintain and on and on. The product owner isresponsible for maximizing the return the business gets on thisinvestment(ROI).Oneway that theproduct ownermaximizesROI is bydirecting theteam toward the most valuable work, and away from less valuablework.Thatis,theproductownercontrolstheorder,sometimescalledpriority, of items in the team’s backlog. In scrum, no-one but theproductownerisauthorizedtoasktheteamtodoworkortochangetheorderofbacklogitems.Another way that the product owner maximizes the value realizedfromtheteam’seffortsistomakesuretheteamfullyunderstandstherequirements. If the team fully understands the requirements, thentheywillbuildtherightthing,andnotwastetimebuildingthewrongthing. The product owner is responsible for recording therequirements,oftenintheformofuserstories(eg,“Asa<role>,Iwant<a feature>, so that I can<accomplish something>”)andadding themto theproduct backlog.Eachof theseusers stories,when completed,willincrementallyincreaseinthevalueoftheproduct.Forthisreason,weoftensaythateachtimeauserstoryisdonewehaveanewproductincrement.

TheProductOwnerRoleinaNutshell:

holdsthevisionfortheproductrepresentstheinterestsofthebusinessrepresentsthecustomersownstheproductbacklogorders(prioritizes)theitemsintheproductbacklogcreatesacceptancecriteriaforthebacklogitemsisavailabletoanswerteammembers’questions

ScrumMaster

The scrum master acts as a coach, guiding the team to ever-higherlevels of cohesiveness, self-organization, and performance. While ateam’s deliverable is the product, a scrum master’s deliverable is ahigh-performing,self-organizingteam.The scrum master is the team’s good shepherd, its champion,guardian, facilitator, and scrum expert. The scrummaster helps theteam learn andapply scrum and related agile practices to the team’sbestadvantage.Thescrummasterisconstantlyavailabletotheteamtohelp them remove any impediments or road-blocks that are keepingthemfromdoingtheirwork.Thescrummasterisnot—werepeat,not—the team’s boss. This is a peer position on the team, set apart byknowledgeandresponsibilitiesnotrank.

ThescrummasterroleinaNutshell:

scrumexpertandadvisorcoachimpedimentbulldozerfacilitator

TeamMember

High-performing scrum teams are highly collaborative; they are alsoself-organizing. The team members doing the work have totalauthorityoverhowtheworkgetsdone.Theteamalonedecideswhichtools and techniques to use, and which teammembers will work onwhich tasks. The theory is that the people who do the work are thehighest authorities on how best to do it. Similarly, if the businessneeds scheduleestimates, it is the teammembers who should createtheseestimates.A scrum team should posess all of the skills required to create apotentially shippable product.Most often, thismeanswewill have ateam of specialists, each with their own skills to contribute to theteam’ssuccess.However,onascrumteam,eachteammember’sroleisnot to simply contribute in their special area. The role of each andevery teammember is to help the team deliver potentially shippableproduct ineachsprint.Often, thebestway fora teammember todothis is by contributing work in their area of specialty. Other times,however, the team will need them to work outside their area ofspecialty in order to bestmove backlog items (aka user stories) from“in progress” to “done.”Whatwe are describing is amindset changefrom “doingmy job” to “doing the job.” It is also a change in focusfrom“whatwearedoing”(work)towhatisgettingdone(results).

TheTeamMemberRoleinaNutshell:

responsible for completinguser stories to incrementally increasethevalueoftheproductself-organizestogetallofthenecessaryworkdonecreatesandownstheestimatesownsthe“howtodothework”decisionsavoidssiloed“notmyjob”thinking

7+/-2

So,howmanyteammembersshouldascrumteamhave?Thecommonruleofthumbisseven,plusorminustwo.Thatis,fromfivetonine.Fewerteammembersandtheteammaynothaveenoughvarietyofskillstodoalloftheworkneededtocompleteuserstories.Moreteammembersandthecommunication

overheadstartstogetexcessive.

ScrumArtifacts

Thesearethetoolswescrumpractitionersusetomakeourprocessvisible.

TheProductBacklog

The product backlog is the cumulative list of desired deliverables fortheproduct.Thisincludesfeatures,bugfixes,documentationchanges,and anything else thatmight bemeaningful and valuable to produce.Generically, they are all referred to as “backlog items.”While backlogitem is technically correct, many scrum teams prefer the term “userstory,” as it reminds us that we build products to satisfy our users’needs.Thelistofuserstoriesisorderedsuchthatthemostimportantstory,the onethat the team should do next, is at the top of the list. Rightbelowit isthestorythattheteamshoulddosecond,andsoon.Sincestories near the top of the product backlog will be worked on soon,they should be small andwell understood by thewhole team. Storiesfurtherdown in the list can be larger and lesswell understood, as itwillbesometimebeforetheteamworksonthem.Each item, or story, in the product backlog should include thefollowinginformation:

Whichusersthestorywillbenefit(whoitisfor)Abriefdescriptionof thedesiredfunctionality (whatneedstobebuilt)Thereasonthatthisstoryisvaluable(whyweshoulddoit)AnestimateastohowmuchworkthestoryrequirestoimplementAcceptance criteria that will help us know when it has beenimplementedcorrectly

TheSprintBacklog

The sprint backlog is the team’s to do list for the sprint. Unlike theproduct backlog, it has a finite life-span: the length of the currentsprint. It includes: all the stories that the team has committed todelivering this sprint and their associated tasks. Stories aredeliverables, andcanbe thoughtofasunitsofvalue.Tasksare thingsthatmustbedone, inordertodeliver thestories,andsotaskscanbethought of as units of work. A story is something a team delivers; atask is a bit of work that a person does. Each story will normallyrequiremanytasks.

BurnCharts

Aburnchartshowsustherelationshipbetweentimeandscope.TimeisonthehorizontalX-axisandscope ison theverticalY-axis.Aburnup chart shows us how much scope the team has got done over aperiodoftime.Eachtimesomethingnewiscompletedthelineonthechart moves up. A burn down chart shows us what is left to do. Ingeneral, we expect thework remaining to go down over time as theteam gets things done. Sometimes the work remaining changessuddenly, when scope is added or removed. These events appear asvertical lineson theburndownchart: a vertical lineupwhenweaddnewwork,ordownwhenweremovesomeworkfromtheplan.

TaskBoard

When the team’s tasks are visible to everyone from across the room,you never have to worry that some important piece of work will beforgotten.The simplest taskboardconsistsof threecolumns: todo,doinganddone. Tasks move across the board, providing visibility regardingwhich tasks aredone,which are inprogress, andwhich are yet tobestarted. This visibility helps the team inspect their current situationand adapt as needed. The board also helps stakeholders see theprogressthattheteamismaking.

DefinitionofDone

Done is awonderfulword;when the teamgets auser storydone it’stimetocelebrate!Butsometimesthereisconfusionaboutexactlywhatthat word “done” means. A programmer might call something donewhen the code has been written. The tester might think that donemeans that all of the tests have passed.The operations personmightthinkthatdonemeansit’sbeenloadedontotheproductionservers.Abusiness person may think that done means we can now sell it tocustomers,andit’s ready for themtouse.Thisconfusionaboutwhat“done” means can cause plenty of confusion and trouble, when thesalespersonaskswhy the team is stillworkingon the samestory thattheprogrammersaidwasdonetwoweeksago!In order to avoid confusion, good scrum teams create their owndefinitionoftheword“done”whenit isappliedtoauserstory.Theydecidetogetherwhatthingswillbecompletebeforetheteamdeclaresastorytobedone.Theteam’sdefinitionmayincludethingslike:codewritten, code reviewed, unit tests passing, regression tests passing,documentationwritten,productownersign-off,andsoon.Thislistofthingsthattheteamagreestoalwaysdobeforedeclaringastorydonebecomestheteams“definitionofdone.”Theteamwilllikelyprintouttheir definition of done as a checklist, and post it next to their taskboard.When the team thinks a story is done, they all gather aroundand review each item, to confirm that it has been completed. Onlythenwilltheteamdeclarethestoryasdone.

TheSprintCycle

Thesprintcycleconsistsofseveralmeetings,oftencalledceremonies:

sprintplanningdailyscrumstorytime

sprintreviewretrospective

It’saboutrhythm

The sprint cycle is the foundational rhythm of the scrum process.Whether you call your development period a sprint, a cycle or aniteration,youare talkingaboutexactly the same thing:afixedperiodoftimewithinwhichyoubiteoffsmallbitsofyourprojectandfinishthem before returning to bite off a few more. At the end of yoursprint, you will be demonstrating working software or thy name isMud.Themorefrequentlytheteamdeliversapotentiallyshippableproductincrement,thegreaterfreedomthebusinesshasindecidingwhenandwhattoship.Noticethatthereare2separatedecisionshere:Istheproductpotentiallyshippable?Thatistosay,isthequalityhighenough that the business could ship it? Are all of the current storiesdone?Thisisadecisionfortheteam.Does it make business sense to ship what we have at this time? Isthereenoughincrementalvaluepresenttotakethecurrentproducttomarket?Thisisadecisionforthebusiness.Additionally,themorefrequentlytheteamdeliversanddemonstratesa potentially shippable product increment, the more frequently theteamgetsfeedback,whichfuelstheimportantinspect-and-adaptcycle.Theshorterthesprintcycle,themorefrequentlytheteamisdeliveringvaluetothebusiness.Asof thiswriting, it iscommonforscrumteamstowork insprintsthatlasttwoweeks,andmanyteamsarestartingtoworkinone-weeksprints.Muchof theoriginalwritingabout scrumassumedamonth-longsprint,andatthetimethatseemedveryshortindeed!The table that follows maps out the various meetings you wouldschedule during a one-week sprint. You don’t have to call themmeetings if you’re allergic to the term or consider meetings to be aformofrepetitivestressinjury;youcancallthemceremonies,asmany

scrum adherents do. The meeting lengths shown are an appropriatestartingpointforateamdoingone-weeksprints.

SprintPlanningMeeting

Sprint planning marks the beginning of the sprint. Commonly, thismeeting has two parts. The goal of the first part is for the team tocommittoasetofdeliverables forthesprint.Duringthesecondpartofthemeeting,theteamidentifiesthetasksthatmustbecompletedinorder todeliver the agreeduponuser stories.We recommendone totwohoursofsprintplanningperweekofdevelopment.

PartOne:“Whatwillwedo?”

Thegoalofpartoneofthesprintplanningmeetingistoemergewitha set of “committed” stories that the whole team believes they candeliverbytheendof thesprint.Theproductowner leads thispartofthemeeting.Onebyone,inpriorityorder,theproductownerpresentsthestorieshewouldliketheteamtocompleteduringthissprint.Aseachstoryispresented, the teammembers discuss itwith the product owner andreview acceptance criteria to make sure they have a commonunderstandingofwhat isexpected.Thenthe teammembersdecide iftheycancommittodeliveringthatstorybytheendofthesprint.Thisprocess repeats for each story, until the team feels that they can’tcommit to any more work. Note the separation in authority: theproductownerdecideswhichstorieswillbeconsidered,buttheteammembers doing the actual work are the ones who decide howmuchworktheycantakeon.

Part2:“Howwillwedoit?”

In phase two of the sprint planning meeting, the team rolls up itssleeves and begins to decompose the selected stories into tasks.Rememberthatstoriesaredeliverables:thingsthatstakeholders,users,and customers want. In order to deliver a story, teammembers willhavetocompletetasks.Taskarethingslike:getadditionalinputfromusers;designanewscreen;addnewcolumnstothedatabase;doblack-box testing of the new feature; write help text; get the menu itemstranslatedforourtargetlocales;runthereleasescripts.Theproductownershouldbeavailableduringthishalfofthemeetingto answer questions. The team may also need to adjust the list ofstories it is committing to, asduring theprocessof identifying taskstheteammembersmayrealizethat theyhavesignedup for toomanyortoofewstories.Theoutputof the sprintplanningmeeting is the sprintbacklog, thelist of all the committed stories, with their associated tasks. Theproduct owner agrees not to ask for additional stories during thesprint,unless the teamspecificallyasks formore.Theproductowneralsocommitstobeingavailabletoanswerquestionsaboutthestories,negotiate their scope, and provide product guidance until the storiesareacceptableandcanbeconsidereddone.

DailyScrum

Thedailyscrum,sometimescalledthestand-upmeeting,is:Daily.Most teams choose to hold thismeeting at the start of theirworkday.Youcanadaptthistosuityourteam’spreferences.Brief.Thepointofstandingupistodiscouragethekindsoftangentsand discursions that make for meeting hell. The daily scrum shouldalwaysbeheldtonomorethan15minutes.Pointed.Eachparticipantquicklyshares:

•WhattasksI’vecompletedsincethelastdailyscrum.WhattasksIexpecttocompletebythenextdailyscrum.Whatobstaclesareslowingmedown.

The goal of this meeting is to inspect and adapt the work the teammembersaredoing, inorder to successfullycomplete the stories thatthe team has committed to deliver. The inspection happens in themeeting; the adaptation may happen after the meeting. This meansthattheteamneedn’tsolveproblemsinthemeeting:simplysurfacingthe issues and deciding which team members will address them isusuallysufficient.Remember,thismeetingisbrief!

StoryTime

In this meeting you will be discussing and improving the stories inyourproductbacklog,whichcontainsallthestoriesforfuturesprints.Notethatthesearenotthestoriesinthecurrentsprint--thosestoriesare now in the sprint backlog. We recommend one hour per week,everyweek,regardlessofthelengthofyoursprint.Inthismeeting,theteamworkswiththeproductownerto:DefineandRefineAcceptanceCriteriaEach user story in the product backlog should include a list ofacceptancecriteria.Thesearepass/failtestableconditionsthathelpusknowwhen then the story is implemented as intended. Some peoplelike to think of them as acceptance examples: the examples that theteamwilldemonstratetoshowthatthestoryisdone.

StorySizing(Estimation)

During story time, the teamwill assigna size (estimate, if youpreferthat term) to stories that haven’t yet been sized. This is the team’sguess athowmuchworkwill be required toget the story completelydone.

StorySplitting

Storiesatthetopoftheproductbacklogneedtobesmall.Smallstoriesare easier for everyone to understand, and easier for the team tocomplete in a short period of time. Stories further down in theproductbacklogcanbe largerand lesswelldefined.This implies thatweneedtobreakthebigstoriesintosmallerstoriesastheymaketheirwayup the list.While theproductownermaydomuchof thisworkon their own, story time is their chance to get help from the wholeteam.As of this writing, the story time meeting isn’t an “official” scrummeeting. We suspect it will be in the future, as all of the highperformingscrumteamsweknowusethestorytimemeetingtohelpkeeptheirproductbackloggroomed.

SprintReview

This is thepublicendof the sprint; inviteanyandall stakeholders tothismeeting. It’s the team’s chance to showoff its accomplishments,thestoriesthathavemettheteam’sdefinitionofdone.Thisisalsothestakeholders’ opportunity to see how the product has beenincrementallyimprovedoverthecourseofthesprint.Iftherearestoriesthattheteamcommittedtobutdidnotcomplete,thisisthetimetosharethatinformationwiththestakeholders.Thencomesthemaineventof thismeeting:demonstrating thestories thatdid get done. Undoubtedly the stakeholders will have feedback andideas, and the product owner and the teammemberswill gather thisfeedback,whichwillhelptheteamtoinspect-and-adapttheproduct.This meeting is not a decision-making meeting. It’s not when wedecide if the stories are done; thatmusthappenbefore thismeeting.It’snotwhenwemakedecisionsorcommitmentsaboutwhattheteamwilldoduringthenextsprint;thathappensinsprintplanning.How long should the sprint review be? We recommend schedulingone-half to one hour for every week of development. That is, if youhaveaone-weeksprint, thenthismeetingmightbe30to60minutes.If you have a two-week sprint, then thismeetingmight need one totwohours.Afteryouhavedoneitafewtimes,youwillknowhowlongyourteamneeds—inspectandadapt!

Retrospective

While the sprint review is thepublicendof the sprint, the teamhasonemoremeeting:theretrospective.Scrumisdesignedtohelpteamscontinuously inspect and adapt, resulting in ever-improvingperformanceandhappiness.Theretrospective,heldattheveryendofeachandeverysprint,isdedicatedtimefortheteamtofocusonwhatwaslearnedduringthesprint,andhowthatlearningcanbeappliedtomake some improvement. We recommend one to two hours ofretrospectivetimeforeachweekofdevelopment.Unlike the traditional “post mortem,” the aim of a retrospective isnevertogeneratealonglaundrylistofthingsthatwentwellandthingsthat went wrong, but to identify nomore than one or two strategicchangestomakeinthenextsprint.It’saboutprocessimprovement.

AbnormalSprintTermination(WhenGoodSprintsGoBad)

In scrum, the basic agreement betweenmanagement and the team isthatmanagementwon’tchangeuprequirementsduringasprint.Still,everyonceinawhilesomethinghappensthatinvalidateseverythinginthesprintplan—abusinessissold,agame-changingtechnologyentersthemarket,acompetitormakesamove.Thedecisiontoterminatethesprintearlyisfundamentallyabusinessdecision,sotheproductownergetstomakethecallonan“abnormalsprinttermination.”Despitethename, neither Arnold Schwarzenegger nor James Cameron need getinvolved.If the product owner does decide to terminate the sprint early, theteamwillbackoutanychangesthattheyhavemadeduringthesprintto avoid the problems that come from half-done work. Holding aretrospective is especially important after a sprint is abnormallyterminated,asithelpstheteamlearnfromtheexperience.

Inspect&Adapt,Baby!

So,why dowe do developmentwork in these short cycles?To learn.Experience is the best teacher, and the scrum cycle is designed toprovide you with multiple opportunities to receive feedback—fromcustomers, from the team, from the market—and to learn from it.What you learn while doing the work in one cycle informs yourplanningforthenextcycle.Inscrum,wecallthis“inspectandadapt”;youmightcallit“continuousimprovement”;eitherway,it’sabeautifulthing.

That’sit!Ready,set,

sprint!

Appendix:Values&Principles

ThevaluesandprinciplesoutlinedintheAgileManifesto,whilenotapartofscrumframework,

servedtoinformthecreatorsofscrumandprovidealotofcontextforunderstandingthewhyofscrum.Wedidn’twritethem,butwe’reincludingthemhereintheirentiretyforyour

edificationandenjoyment.

AgilePrinciples

Ourhighestpriorityistosatisfythecustomerthroughearlyandcontinuousdelivery

ofvaluablesoftware.Welcomechangingrequirements,evenlatein

development.Agileprocessesharnesschangeforthecustomer’scompetitiveadvantage.

Deliverworkingsoftwarefrequently,fromacoupleofweekstoacoupleofmonths,witha

preferencetotheshortertimescale.Businesspeopleanddevelopersmustwork

togetherdailythroughouttheproject.Buildprojectsaroundmotivatedindividuals.

Givethemtheenvironmentandsupporttheyneed,andtrustthemtogetthejobdone.

Themostefficientandeffectivemethodofconveyinginformationtoandwithinadevelopment

teamisface-to-faceconversation.Workingsoftwareistheprimarymeasureofprogress.Agileprocessespromotesustainabledevelopment.Thesponsors,developers,andusersshouldbeable

tomaintainaconstantpaceindefinitely.Continuousattentiontotechnicalexcellence

andgooddesignenhancesagility.Simplicity--theartofmaximizingtheamount

ofworknotdone--isessential.Thebestarchitectures,requirements,anddesigns

emergefromself-organizingteams.Atregularintervals,theteamreflectsonhow

tobecomemoreeffective,thentunesandadjustsitsbehavioraccordingly.

AgileValues

IndividualsandinteractionsoverprocessesandtoolsWorkingsoftwareovercomprehensivedocumentation

CustomercollaborationovercontractnegotiationRespondingtochangeoverfollowingaplan

Source:agilemanifesto.org

AbouttheAuthors

ChrisSimsisaCertifiedScrumTrainerandagilecoachwhohasbeenhelpingteamsimprovetheirhappinessandproductivitysincetheturnof the century.He hasmade a living in roles such as: scrummaster,product owner, engineering manager, C++ developer, musician, andauto mechanic. Chris is the founder of Agile Learning Labs and afrequentpresenteratagileconferences.

Hillary Louise Johnson is an author and former business journalistwho has written on innovation, technology and pop culture for Incmagazine and the Los Angeles Times. As an intellectual propertyconsultantshehasdraftednumeroustechnologypatents.Shehasbeeneditor-in-chief of several print and online publications and is nowAgileLearningLabs’creativedirector.

Loveit?Hateit?Reviewit!

Amazon reviews help other readers like you discover books, sowhetheryouadored thisbookor loathed it topieces,weurgeyou totakeafewmomentstoshareyoursentimentsatamazon.com.

Ifyouenjoyedthistitle...

...you can learn even more from The Elements of Scrum. Pepperedwithanecodotes,illustrationsandallofthesupportingpracticesyou’llneed to be agile,The Elements of Scrum has helped thousands ofreaders become happier andmore productive.Here is what some ofourAmazonreadershavesaidaboutElements:

“IfyouwanttounderstandtheessentialsofAgiledevelopmentandScrum,TheElementsof

ScrumbyChrisSimsandHillaryLouiseJohnsonisamustread.”-DaveMoran

“Bravo.6stars.Iwishallcomputerbookswerewrittenlikethis.”-T.McCann

“Asaconsultantwhoworksinagile,thisisthebookI’vebeenwaitingfor.”-LizLewison“Forthoseonlydancingwiththeideaoflearningscrumandagile,Ihavethreewords—Readthis

Book.”-BrendanKane

You’llfindTheElementsofScrumonAmazonfor$29.95tradepaperback,$9.99Kindle.