Agile User Experience Design ’ A Practitioner s Guide to Making It Work Diana DeMarco Brown AMSTERDAM(cid:1)BOSTON(cid:1)HEIDELBERG(cid:1)LONDON(cid:1)NEWYORK(cid:1)OXFORD PARIS(cid:1)SANDIEGO(cid:1)SANFRANCISCO(cid:1)SINGAPORE(cid:1)SYDNEY(cid:1)TOKYO MorganKaufmannisanimprintofElsevier AcquisitionsEditor:MegDunkerley DevelopmentEditor:HeatherScherer ProjectManager:MohanambalNatarajan Copyeditor:GnomiSchriftGouldin MorganKaufmannisanimprintofElsevier 225WymanStreet,Waltham,MA02451,USA Firstedition2013 Copyright(cid:1)2013ElsevierInc.Allrightsreserved Nopartofthispublicationmaybereproduced,storedinaretrievalsystemortransmittedinanyformorbyanymeanselectronic, mechanical,photocopying,recordingorotherwisewithoutthepriorwrittenpermissionofthepublisherPermissionsmaybe soughtdirectlyfromElsevier‘sScience&TechnologyRightsDepartmentinOxford,UK:phone(+44)(0)1865843830;fax (+44)(0)1865853333;email:permissions@elsevier.com.Alternativelyyoucansubmityourrequestonlinebyvisitingthe Elsevierwebsiteathttp://elsevier.com/locate/permissions,andselectingObtainingpermissiontouseElseviermaterial Notices Knowledgeandbestpracticeinthisfieldareconstantlychanging.Asnewresearchandexperiencebroadenourunderstanding, changesinresearchmethodsorprofessionalpractices,maybecomenecessary.Practitionersandresearchersmustalwaysrelyon theirownexperienceandknowledgeinevaluatingandusinganyinformationormethodsdescribedherein.Inusingsuch informationormethodstheyshouldbemindfuloftheirownsafetyandthesafetyofothers,includingpartiesforwhomthey haveaprofessionalresponsibility. Tothefullestextentofthelaw,neitherthePublishernortheauthors,contributors,oreditors,assumeanyliabilityforany injuryand/ordamagetopersonsorpropertyasamatterofproductsliability,negligenceorotherwise,orfromanyuseor operationofanymethods,products,instructions,orideascontainedinthematerialherein. LibraryofCongressCataloging-in-PublicationData Applicationsubmitted BritishLibraryCataloguinginPublicationData AcataloguerecordforthisbookisavailablefromtheBritishLibrary ForinformationonallMorganKaufmannpublications visitourwebsiteatwww.mkp.com PrintedandboundinUSA 1314151617 10987654321 ISBN:978-0-12-415953-2 To my daughter, my best creation Introduction WhenIfoundoutthatIwasgoingtobesupportingaprojectusingScrum,Iwas immediately wary. I did not really know much about Scrum or Agile but had thesensethatthesethingsmovedatafastpaceanddidnotreallytakeUXinto consideration.However,Ihadnochoiceaboutwhichdevelopmentprocessmy teamchose, soI set my trepidations asideand got ready to supportmy team. IwasfortunatethatsomeinternalexpertswhowereadvocatesoftheUXteam wereworkinginparallelsprints,orworkingasprintahead,tothedevelopment team. Their model seemed very logical and comfortable, and I was happy to applythetechnique.OnceIgotstartedthough,Inoticedthatalotoffactorsin mysituationdidnotmatchtheirexperienceandIwasnotentirelysurehowto modify the technique to fit. My team was not colocated (although not extremely so), the team was larger than recommended, and the project had a significant infrastructure piece in addition to the user interface. None of the issues was adeal breaker,but Ineededtoadjust myprocess andI was always veryuncertain about whether Iwas beingAgile enough. After finishing the project, I shared my experience at a local usability profes- sionals’conference,anditwaseye-opening.Peopleweresohungryforinsight andguidance andhadmanyofthesamequestions.However,sincetherewas awidevarietyinsituations,theanswertothosequestionsmightbedifferentfor everyone.IwasblownawaybythedifferentimplementationsofAgileUXand felt like I was not seeing enough of that diversity reflected in the dialog happening around Agile and UX. I felt that had I known there were so many ways to do Agile UX and what they were, this would have given me more confidence about my approach. I thought, “Someone should write a book.” Then, afew years later,I did. The goal of this book is to show that there are many ways for a UX team to succeed, and fail, at being Agile and to illustrate that using the same set of tactics could lead to either outcome, depending on the situation. The case studiesshowthattherearemanywaystobeAgileandmorethanafewwaysfor aUXteamtodowellinanAgile environment.Iexaminewhatcontributesto xi xii Introduction a team’s success and what factors to consider to determine the best path for your team to take to achieve apositive outcome.After reading thisbook, you willhavethetoolsyouneedtodeterminewhatAgileUXmeansforyouinyour situation. ACKNOWLEDGMENT DougDeMarcoofDeMarcoInteractivecreatedthefantasticillustrationsinthisbook. About the Author DianaBrownhasbeendesigninginteractionsandsoftwareinterfacesforover a decade. She spent a good portion of that time talking to end users and findingwaystoencouragethemtotalktoher.Muchoftherestofhertimehas been spent talking to her development teams and finding ways to encourage them to talk to her. She continues to be amazed by all the cool things that software can do. xiii CHAPTER 1 Introduction to Agile CONTENTS Introduction...................................................................................................2 Agile Valuesþ UX........................................................................................4 Individualsandinteractionsoverprocessesandtools..................................................5 Workingsoftwareovercomprehensivedocumentation................................................6 Customercollaborationovercontractnegotiation..........................................................7 Respondingtochangeoverfollowingaplan..................................................................8 Agile Principles þ UX...................................................................................9 Principle1..........................................................................................................................10 Principle2..........................................................................................................................11 Principle3..........................................................................................................................11 Principle4..........................................................................................................................12 Principle5..........................................................................................................................13 Principle6..........................................................................................................................14 Principle7..........................................................................................................................15 Principle8..........................................................................................................................16 Principle9..........................................................................................................................17 Principle10........................................................................................................................18 Principle11........................................................................................................................19 Principle12........................................................................................................................19 Common Methods.......................................................................................20 Crystal................................................................................................................................20 ExtremeProgramming(XP).............................................................................................20 Scrum..................................................................................................................................21 Hybridagile,orcustomagile..........................................................................................23 Kanban...............................................................................................................................25 Scrumban...........................................................................................................................26 LeanUX..............................................................................................................................27 Common Terms...........................................................................................28 Chickensandpigs............................................................................................................28 Productowner...................................................................................................................28 Scrummaster.....................................................................................................................29 Sprint..................................................................................................................................30 Productbacklog.................................................................................................................30 Userstories........................................................................................................................31 1 AgileUserExperienceDesign.http://dx.doi.org/10.1016/B978-0-12-415953-2.00001-7 Copyright(cid:1)2013ElsevierInc.Allrightsreserved. 2 CHAPTER 1: Introduction to Agile Epic.....................................................................................................................................32 Planningpoker..................................................................................................................32 Story-pointestimation......................................................................................................32 Acceptancecriteria...........................................................................................................34 Burn-downchart...............................................................................................................34 Spike...................................................................................................................................35 AgileFall.............................................................................................................................35 JeffPatton..........................................................................................................................36 Summary......................................................................................................38 References...................................................................................................38 INTRODUCTION TounderstandwhatitmeanstopracticeanAgileformofuser-centereddesign, itisimportanttohaveasenseofwhatexactlyAgilemeansandwheretheterm came from. Since the Agile methodology has a deep, rich history and is continually evolving, it has become the subject of many books, blogs, white papers,conferencepresentations,andwebsites,allofwhichhavetheirowntake on the value system and its methods. This chapter touches on only the most common terms and concepts and those that might be most relevant to a user experiencepractitioner.Iencourageeveryonetospendsometimeexploringthe manyresourcesthatareavailable to geta deeper understandingof thephilos- ophyandthevariousmethodsforapplyingitthathavegrownupalongtheway. It is also important to recognize that there is no one single right way to implementAgiledesign.Atitscore,“Agile”isasetofvaluestouseascompassto guideateamthroughtheproductionofsoftware.Whateverprocessortoolsare usedandhowtheyareappliedaresecondarytotheoverallgoalsofempowering ahighlyfunctionalteamasitbuildsgreatsoftwaretothedelightofitsendusers. Agileisatermthatgrewoutofeffortsinthe1990stofindabetterdevelopment method for producing software. Traditional methods, such as the waterfall method, were starting to be recognized as a bit unwieldy. Consumers were expecting more of their software in terms of quality and functionality, and production cycles needed to change in order to create a product that would satisfyendusers.Additionally,productioncyclesneededtobeabletoadaptand accommodate the reality of shifting requirements. Waterfall development makesitespeciallychallengingforteamstorespondtoissues,mostlybecauseit isinherentlyunabletodiscoverseriousproblemswiththedesign,architecture, orthecodeitselfearlyinthecycleandcanreallyidentifythemonlywhenitis toolateforacorrection.Notknowingwhatproblemsmightexistuntiltheend of the release cycle results in a lower-quality product or longer release cycle. Traditional methods are also prone to creating silos, where product managers throw requirements “over the wall” to designers, who then throw their design specificationsoverthewalltodevelopmentteams,whothrowtheircodeoverto Introduction 3 a quality team, that eventually authorizes the release of a product. Due to the limited interaction and communication among these teams during the production of eachdeliverable,eachteam is playinga game of telephone and putting its own interpretation on the requirements or the specifications. As in thetelephonegame,theendresultveryrarelymatchestheoriginalintention. Development teams began experimenting with new techniques like Extreme Programming, Adaptive Programming, Scrum, and other methods to find a better way to produce high-quality software and meet demands without requiring developers to write code 24 hours a day. In 2001, practitioners of a variety of these philosophies got together in Utah and created the Agile Manifesto. The manifesto, and its accompanying 12 principles, captures the spirit of what all these methods were trying to achieve and is an important starting point for an organization that is consider adopting Agile practices. Reading the values expressed in the Agile Manifesto is always a good way to checkonwhetherornotyouareontrackwithyourownAgileimplementation. Whilethemethods,techniques,andterminologyhaveevolvedsince2001,the core values of Agile havenot. Themanifesto eloquentlystates: “Weareuncoveringbetterwaysofdeveloping softwarebydoingitandhelpingothersdoit. Throughthisworkwehavecometovalue: Individualsandinteractionsoverprocessesandtools Workingsoftwareovercomprehensivedocumentation Customercollaborationovercontractnegotiation Respondingtochangeoverfollowingaplan Thatis,whilethereisvalueintheitemson theright,wevaluetheitemsontheleftmore” TheManifestoforAgileSoftwareDevelopment,agilemanifesto.org FIGURE1.1 Theagileprocess. 4 CHAPTER 1: Introduction to Agile AGILE VALUES D UX The manifesto provides the best guidancefor and is the most succinct expres- sionofthevaluesthatshoulddriveanAgileorganization.Adescriptionofthe principles behind the Agile Manifesto is provided on the website, and it gives additional insight into the manifesto, but the heart of the matter is very well expressedinthemanifestoitself.Whilereferencingsomethingthatwaswritten solongagomightfeeloldfashioned,Ifindthatthesevaluesarejustasrelevant now as when they were first created. In software years, 2001 was a very long timeago;andwhileitwasnotquitetheDarkAges,itmightwellbeanalogous totheAtomicAge.Afterall,2001wastheyearthatmanyovervalueddotcoms wentunder,thefirst-generationiPodswereintroduced,MicrosoftreleasedXP, and several years ahead of the introduction of the ubiquitous Facebook. UX (userexperience)practitionersareworkingtodaywhohavenomemoryofthat time. With all the focus on Agile in recent years and the birth of so many variations on the theme, it is fair to assume that the movement has evolved beyonditsoriginalmanifesto.Afterall,howmanysoftwareconceptsstillhold water over a decade later? That assumption is false. All the children of the original Agile movement still share the core values expressed in the Agile Manifesto and really just use different tactics to create an environment that embodies the spirit of the original statement. All these years later, software productionteamsstillstrugglewithprocessesthatoftenfocusonthemilestone deliverables instead of keeping their eyes on the shipping product. Rarely is areleasecyclenotsubjecttochangingneedsfromstakeholders,butrarerstillis the process that can support responding to such a changedunless you are working in an Agile environment. The intention of the Agile Manifesto is to defineavaluesystemthatallowsforthecreationofaculturethatcanrespond tothesesituations,whilerecognizingthevalueoftheindividualteammember, andproducegoodsoftware.WhiletheAgileManifestolaysoutthecorevalues ofanAgileenvironment,manytechniquescanbuildaprocessandaframework to support those values. Examining these values through a UX lens can show that there is anatural relationship between the two. Unfortunately, at no time have UX professionals gotten together and hashed out a manifesto of UX values and principles that came to be the standard to whichweallholdourselves.Infact,despitedefinitionsoftheprocessforuser- centered design, there is no formal expression of its value system, beyond the ideathatwewanttokeeptheuser’sneedscentraltothedesignprocess.Things start to get even more vague regarding UX principles. It is not that no UX principlesarewrittendown,butthatdifferentUXprinciplesarewrittendown by many people. Quite a few people have their own spin on UX design prin- ciples,includingMicrosoft,whichhasdefined theUXprinciplesfor Windows andsharedtheseprinciplesonitswebsite(seehttp://msdn.microsoft.com/en- us/library/windows/desktop/dd834141.aspx). Most of the definitions of UX