business analysis methodology book: business analyst's guide to requirements analysis, lean ux...

99

Upload: others

Post on 11-Sep-2021

5 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 2: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

BusinessAnalysisMethodologyBook

BusinessAnalyst'sGuidetoRequirementsAnalysis,LeanUXDesignandProjectManagementatLeanEnterprisesandLeanStartups

*IncludingMobileSoftwareDevelopmentProjectCaseStudy

Page 3: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Copyright©2015EMRAHYAYICI

Allrightsreserved.Nopartofthisbookmaybereproducedortransmittedinanyformorbyanymeans,electronic,mechanical,photocopying,recordingorotherwise,without

thepriorwrittenpermissionofthepublisher.

Page 4: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

AbouttheAuthor

EmrahYayici is theauthorof thebest-sellingBusinessAnalyst’sMentorBookandUXDesignandUsabilityMentorBook.HeisoneofthemanagingpartnersofUXservices,BA-WorksandKeytorc.

He started his career as a technology consultant at Arthur Andersen andAccenture.Afterwardhe ledglobalenterprise transformationprojectsatBeko-GrundigElectronics.

During his career he has managed multinational and cross-functional projectteamsinbanking, insurance, telecommunications,media,consumerelectronics,and IT industries. He is now sharing his experience about business analysis,business development, product development, customer experience design, UXdesign,usabilitytesting,andqualityassurancebypublishingarticlesandbooks,leadingtrainingsessions,andspeakingatconferences.

He contributes to UXPA (User Experience Professionals Association) as amember and IIBA® (International Institute of Business Analysis) as a localchapter president. He also contributed to ISTQB® (International SoftwareTestingBoard)asaformerinternationalboardmember.

Page 5: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Preface

Companies have to develop innovative and high-quality products faster thantheir competitors to create temporary monopoly periods with maximumprofitability.However,theyusuallyhavetightdeadlinesandlimitedbudgetsfornew product development projects. C-suite executives and managers alwayswant to get quick results and rarely accept putting the brakes on a productlaunch.

To overcome this challenge, high-performing companies apply a “lean”approach at every stage of their product development life-cycle (PDLC): -Enterprise Architecture Management -Strategic Analysis and Product ScopeDefinition

-RequirementsGathering

-RequirementsDocumentation

-UXDesignandUsability

-TechnicalDesign,Development,andOperations

-QualityAssuranceandTesting

-ProjectManagement

Bestpracticetechniquesandprinciplespresentedinthisbookcanbeusedbyabroadrangeofpractitioners,including:-businessanalysts

-entrepreneurs-consultants-productmanagers

-productowners

-marketingspecialists

-projectmanagers

-UXdesigners

Page 6: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

-developers,and

-QAteams

in development of any kind of products, ranging frommobile applications toconsumerelectronicsthatcontainsoftwaretechnology.

Thebookincludesacasestudyaboutamobileapplicationdevelopmentprojecttoshowhowtoapplytheprinciplesandtechniquesexplainedineachchapter.

Thereisamisperceptionthatleanapproachisonlyapplicableforstart-upsandsmall-scale companies that usually don’t have enough technical and financialresourcesforproductdevelopment.

On the contrary, C-suite executives and managers of companies of all sizesshouldapplyleanapproachintransformingtheirenterpriseoperatingmodelsto:

-fosterinnovation,

-achievefastertimetomarket,and

-preventwasteandimproveprofitability.

Page 7: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

TableofContents

1.LeanPrinciplestoAchieveInnovationandFasterTimetoMarket

2.EnterpriseArchitectureManagement

3.StrategicAnalysisandProductScopeDefinition

4.WhichMethodologyisBestfortheLeanApproach:WaterfallorAgile?

5.RequirementsGathering

6.RequirementsDocumentation

7.UXDesignandUsability

8.TechnicalDesignandDevOps

9.QualityAssuranceandTesting

10.ProjectManagement

Page 8: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

1.LeanPrinciplestoAchieveInnovationandFasterTimetoMarket

Page 9: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Companies have to develop innovative and high-quality products faster thantheir competitors to create temporary monopoly periods with maximumprofitability.However,theyusuallyhavetightdeadlinesandlimitedbudgetsfornewproductdevelopmentprojects.

To overcome this challenge, high-performance companies apply a “lean”businessanalysis,design,anddevelopmentapproach thathas itsorigins in theToyotacarproductionsystem.

Lean mainly focuses on eliminating muda (waste) throughout the productdevelopment lifecycle (PDLC) and passing resource savings to innovativeprojects.

Wasteeliminationcanbeachievedbyinjectingthefollowingleanprinciplesintothecompanies’DNA:

1.BeValueOriented

-Focusonproducingoutcomes(value)ratherthanoutputs(deliverables).

-Alwaysprioritizeproduct features; focuson“must-have”rather than“nice-to-have"ones.

-Eliminate thewaste of low-priority product features that are not essential forcustomers.

2.BeCustomerCentered

-Belikethesunbutnotthemoon;illuminateyourselfwiththelightofyourowncustomersinsteadofyourcompetitors.Concentrateonbeingmoreresponsivetotheneedsofyourtargetcustomersinsteadofbenchmarkingyourselfwithyourcompetitors.

-Be customer centric rather than product centric. Consider products not as anobjectivebutasatooltomeetyourcustomers’needs.

-Developproductsaroundyourcustomers.Alwayslistencloselytothe“voiceofyourcustomers”throughoutPDLC.Setupandmaintainacontinuouscustomerfeedbackloop.

Page 10: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

-Ask customers about their needs but not their proposed solutions.RememberHenryFord’sfamousquotation:“IfIhadaskedpeoplewhattheywanted, theywouldhavesaidfasterhorses.”

3.BeIterative

-Start yourproductdevelopment journeywith small steps.Thinkbig, but startsmall.

-Bepatient;rememberthatRomewasnotbuiltinaday.

-Move evolutionary rather than revolutionary: Use prototypes to gather earlycustomerfeedback.Attheinitialiteration,releaseacoreversionoftheproductincluding only high-priority features. In following iterations, use customerfeedbackfrompreviousreleases torefine theproductbyadding,updating,andevendroppingfeatures.Iterateuntiltheproductsatisfiesbusinessandcustomerneeds.

4.BeSimplistic

-Rememberthatlessismuchmoreintheleanapproach.Donotcomplicateit.

-Focuson“justenough”andwhatisreallynecessarytosatisfycustomerneeds.

-Appreciate downsizing the product by removing nonessential features, ratherthanupsizingitwithbellsandwhistles.

-Indeterminingproduct features, thinkas ifyouaredecoratinga smallhouse.Don’t make your users feel claustrophobic as if they’re in a small, crowdedspacewithalotoffurniture.

5.Don’tBeAfraidofEarlyFailure

-RememberthefamousquotationfromAmericanscientistandauthorDr.JamesJayHorning:“Goodjudgmentcomesfromexperience.Experiencecomesfrombadjudgment.”

-Be adaptive, learn early from failures in initial iterations, and use thisexperienceforlaterones.

-Focusonkaizen,whichmeanscontinuousimprovement,atalllevelsofPDLCbyusinglessonslearnedatpreviousiterations.

Page 11: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

6.OptimizetheWorkFlow

-Act“justintime”throughoutPDLC.Requirementsanalysisanddesignartifactsrepresent WIP (work in process) inventories in the product developmentlifecycle.CreatethemattherighttimeandwithsufficientdetailtopreventWIP-levelwaste.

Page 12: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

2.EnterpriseArchitectureManagement

Page 13: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

According to the lean approach, every single project in a company shouldsupportcorporatestrategies.Inotherwords,eachproject’sobjectives(businessrequirements) should be alignedwith corporate strategies.Otherwise companyresourcesarerootedinthewrongdirection,andthatresultsinprojectportfolio-levelwaste.

Toensurestrategicalignmentandpreventwaste,requestsfromallbusinessunitswithin the company for new and enhanced products should be received,evaluated,andprioritizedbyadedicatedgroupofpeople.

In large-scale companies that create products containing software technology,thisdedicatedgroupmaybeaseparateenterprisearchitectureteamthatworksincoordination with company executives to understand business strategies,evaluatebusinessunitrequestsagainstthesestrategiesandsteertechnicalteamsin building products thatmeet today’s and tomorrow’s business and customerneeds.

Since product development takes a considerable amount of time, enterprisearchitects should guide technical teams in creating a flexible technicalarchitecture that can serve both today’s and tomorrow’s new productdevelopment initiatives. Otherwise technical limitations become a bottleneckratherthananenablerforthecompany.

The enterprise architecture profession requires business knowledge, technicalskills, and the ability to see the big picturewith a bird’s-eye view.Hence themost suitable people to fill enterprise architecture positions are experiencedbusiness analysts, product managers, and project managers who gain thesecompetenciesnaturally aspart of their profession.Thus in small-andmidsizedcompanies,projectmanagementoffices(PMOs),productmanagementteams,orateamofexperiencedbusinessanalystsshouldberesponsibleforevaluatingandprioritizing product development/enhancement requests from all business unitsandensuringthealignmentofbusinessandtechnicalarchitectures.

AirTrafficControlTower

Inourclients,wewitnessanoverwhelmingnumberofneworenhancedproductdevelopment requests from business units. Managing these requests is like

Page 14: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

managingtheairtrafficcontroltowerataverybusyairport.

Ahugenumberofrequestswaitinginthedemandmanagementpipelinecreatesahightechnicaldebt.

Despitealltheirhardwork,mosttechnicaldepartmentsareblamedfornotbeingable tomeet the expectationsofbusinessunits.Businessunitsmostly criticizetechnicaldepartmentsfornotdeliveringneworenhancedproductsfastenough.

AccordingtoEinstein’srelativitytheory,observationsthatyoumakeabouttimedifferfromobservationsofotherswhoaremovingatdifferentspeeds.Similarly,projectdurationsarerelativefortechnicalteamsandbusinessunitsofthesamecompany.Whilesixmonthswillbeconsideredachallengingtimeframebymosttechnical teams to develop a new product, it will be considered as a longdurationbybusinessunits.

If delivered late, product development projects lose their importance for thebusiness due to rapidly changingmarket conditions and fierce time-to-marketpressures.

Ifyousearchfor therootcauseof technical teams’ latencies,youwillsee thatthey canonly allocate limited time to thedevelopment of newproducts.Theyspend the majority of their time on an overwhelming number ofenhancement/modificationrequestsforexistingproductsto"keepthelightson.”

“KeeptheLightsOn”Projects

Ahighnumberof these enhancement /modification requests alsodemotivatesbusinessanalysts,productmanagers,developers,andprojectmanagersbecause,instead of being involved in new and innovative projects, they have to spendtheirtimefirefightingexistingproducts.

If the additional cost of these enhancement / modification requests are nottracked systematically, the total cost of ownership for existing products willreachaveryhighamount.Usuallythistotalamountoutweighsthereplacementof the existing product with a new one and creates product enhancement /modification-levelwaste.

Sometimes enhancement/modification requests are classified under the samecategorywithmaintenancerequests.Thisisalsoaninappropriateapproachsincemaintenanceisadifferentcategory,anditsaimistoensurecontinuousoperation

Page 15: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

of a product rather than to enhance its attributes. Each product should have aseparatemaintenanceandenhancement/modificationtracktoidentifythebesttimetototallyreplaceit.

Thestatusoftheseenhancement/modificationrequestsshouldbecontinuouslyreviewed.Someoftherequestswaitinginthepipelinemaybecomeobsoletedueto changing business conditions. These obsolete requests should be identifiedand eliminated to optimize the utilization of technical resources and preventwaste.

CaseStudy:MobileApplicationDevelopmentProject

A local CEC (consumer electronics company) outsourced its requirementsgathering,documentation,andanalysisprocesstoBA-Works.

CompanyOverview

TheCECsoldTVsets, speakers,homecinemasystems,andDVDplayersviaindependentdealerstores.Thesedealerstoreswerealsoresponsibleforproductdeliveryandrepair.

The CEC worked with an outsourced call center company that was onlyresponsibleforcustomerservice.Ithadnodirectsalestocustomers.

TheCECmanageditsprocurement,inventory,accounting,andsalesoperationsonanERPsystemandmarketingoperationsonaCRMsystem.

BusinessNeed

The CEC’s website was only being used to present product and campaigninformation. There were no sales on the web channel. At that time the CECdidn’thaveamobileapplication.

For the last two years, discounted prices on e-commerce websites had beendrivingtheCEC’scustomerstothecompetition.

Toovercomethissituation,theCMO(chiefmarketingofficer)oftheCECwasconsidering creating the company’s own online sales channels. The CMOplanned to initiate the online strategywith amobile application. At that timeother consumer electronics companies didn’t havemobile applications for this

Page 16: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

localmarket.TheCMOwantedtomaketheCECthefirstconsumerelectronicscompany that used mobile as a sales channel. He discussed the mobileapplicationideawithhisteammembersandaskedthemtomoveforward.

The company’s marketing business unit entered this request on the CEC’sdemandmanagementsystemasanurgent,high-prioritydemand.Theynotedthattheywantedtoreleaseamobilesaleschannelearlierthancompetitors,andthustheprojecthadtobecompletedwithintwomonthsatthelatest.

On the followingpages, the lean approach, as applied to thedevelopment andrelease of theCEC’smobile application, is explained in detail to help readersbetterunderstandtherelevantcontentineachchapterofthebook.

Page 17: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

3.StrategicAnalysisandProductScopeDefinition

Page 18: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Theleanapproachbringsapurpose-led,value-orientedmindsetthatnecessitatesasharedvisionamongallprojectstakeholders.

Business analysts should start every project by defining the businessrequirements that explain the vision and value proposition of the product.Business requirements should clearly answerwhy customersneed that specificproduct.

Business analysts should interview target customers at the beginning of theproject and validate that the defined business requirements can resolvearticulatedcustomerneeds.

Cleardefinitionofbusiness requirementsat thebeginningof theproject steerseverystakeholderinthesamestrategicdirection.Thismitigatestheriskofscopecreep due to potential change requests (CRs), which result in waste due torework.

Dependingon the size of the project, business requirements can be defined indifferenttypesofproductscopedocuments:

1.Business-CaseDocument

Inlarge-scaleprojects(usuallycalledType-Aprojects)thathaveenterprise-levelimpact, business requirements should be documented on a business-casedocument.Thebusiness-casedocumentshouldinclude:-Businessrequirements:toclarifywhythenewproductisneeded

-Scope: todefineandprioritizeproduct features thatwill satisfy specificgoalsandproblemsoftargetcustomers

-Context:toanalyzewhichotherproductsandsystemstheproductwillworkinintegrationwith

-Costvs.benefitanalysis:tobetterunderstandthefeasibilityofthenewproduct.Thefeasibilityofanewproductshouldbeanalyzedbasedonthedefinedscope,because a feasible product may become infeasible depending on the selectedfeatures.

-Risks:toidentifyandmitigatepossiblenegativeconsequencesofreleasingthenewproduct.

Page 19: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

2.VisionandScopeDocument

Formedium-andsmall-scaleprojects(usuallycalledType-Bprojects),businessrequirements should be documented on a vision and scope document. Thisdocumentshouldincludefeaturesoftheproposedproductthatwillbedeliveredin each release and provide context information that shows the high-levelintegrationoftheproductwithotherproductsandsystems.

3.SOW(StatementofWork)Document

For enhancement/modification requests (usually called Type-C projects) onexisting products that usually last less than onemonth, there is no need for abusiness-caseorvisionandscopedocument.Aclearexplanationofthebusinessneedinaone-pageSOWdocumentisjustenoughtodescribethescopeofwork.These requests arebetter fulfilledby amore agile approachwithout toomuchdocumentation.

RipplingEffect

On any scope document, business requirements should be defined in specific,purpose-led,achievable,andcrystalclearstatements.

A clear definition of business requirements at the start of the project is veryimportant, because at later stages of the project, the functional, nonfunctional,and technical requirements, and the business rules of the product should bedefinedconsistentwiththebusinessrequirements.Wrongdefinitionofbusinessrequirements will have an adverse rippling effect on all of these low-levelrequirementsandbusinessrules.ThiswillresultinwasteduetoahighnumberofCRsanddefects.

ParadoxofChoice

Havingmanyfeaturesisnotanindicatorofeleganceorqualityinleanproductdevelopment.

On the contrary, as psychologist Barry Schwartz describes it in his bookParadoxofChoice:WhyMoreIsLess,choiceoverloadcreatesdecision-makingparalysis,anxiety,andstressratherthanbringingmoresatisfactiontocustomers.

Page 20: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

A lean approach, delivering “maximumvalue”with “just enough” features, isthe ultimate goal. Having a formal prioritization process is one of thepreconditionsforapplyingthisapproach.

Withoutaprioritizationprocess,businessunitsfeelfree torequestanyproductfeature as if the project has unlimited resources. The features requested bybusiness units should be prioritized according to two main criteria: -businessvalueand,

-implementationdifficulty.

Businessvaluedependson thealignmentofa feature tobusiness requirementsandcustomerneeds.Theitemswithhighbusinessvalueandlowimplementationdifficulty should be rated as high priority, while the ones with low businessvalueandhighimplementationdifficultyshouldberatedaslowpriority.

The rest of the features should be labeled as medium priority and prioritizedaccording to their expected frequencyof use.Mediumpriority features canberelabeled as high priority if they have high frequency of use.Otherwise, theymovetothelowpriorityquadrant.

TimetoMarket

Page 21: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Whentimetomarketiscriticalfortheproduct,theprojectshouldbeclassifiedas a “fast-track” one. In these time-sensitive, fast-track projects, businessanalystsandmanagersshouldconvincebusinessunits tofocuson“must-have”features rather than “nice-to-have” features and try to generate “fair-value”outcomesinaniterativeway.

80/20Rule

Regardless of time-to-market constraints, business units are always eager toexpandthescopeofproductsbyaddingnice-to-havefeatures.However, inourexperiencethemajorityofusersonlyuseaminorityoftheproductfeatures.Thisisbigsourceofscope-levelwaste.

When business units insist on nice-to-have, low-priority features, businessanalysts and project managers should remind them of the famous phrase inVoltaire’s poem “La Begueule”: “perfect is the enemy of good.” The phrasesuggeststhatinsistingonperfectionoftenresultsinnoimprovementatall.

BenchmarkingandReverseEngineering

Business units also have a tendency to enlarge the product scope bybenchmarkingcompetitors’productsandrequestingalloftheirfeatures.

Although benchmarking competitors’ products is a fast way of determiningproduct features, it is not appreciated at every phase of lean productdevelopment.

Inaleanapproach,projectstakeholdersshouldbelookingat“whatproblemsofmytargetcustomersshouldmyproductsolve”insteadof“whatmycompetitorsaredoing.”

Afterproductfeaturesaredefined,benchmarkingcanthenbeusedtofastenlaterphasesofproductdevelopmentbyexploringhowcompetitorsimplementsimilarfeatureswithoutreinventingthewheel.

Itshouldalsoberememberedthateventhebestcompetitorsdon’talwaysdotheright things. Thus benchmarking can also result in copying competitors’mistakes. In one of BA-Works projects, our team was responsible forbenchmarkingthecustomerinteractionchannelsofaglobalhotelchainwithitscompetitors.Duringthestudyourteamnoticedthatthemajorityofcompetitors

Page 22: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

had common right things and common wrong things on their customer-interaction channels (web, call center, mobile, and social media). This was aresultofacopy-and-pasteapproach.Althoughcopyingcompetitorsisafastway,companies should first focus on finding ways to differentiate themselves inprovidingthebestcustomerexperience.

CoreVersionofaProduct

TheleanapproachsuggeststhefollowingflowinPDLC:

-Deploy the first releasewith a core version of the product, and get customerfeedbackasearlyaspossible.

-At each following iteration, use previous customer feedback to refine theproductbyadding,updating,andevendroppingfeatures.

-Iterateuntiltheproductsatisfiesbusinessrequirementsandcustomerneeds.

Thecoreversionofaproduct shouldhaveaminimumsetof features that cansolve the main problem of target customers. Popular terms such as MVP(minimumviableproduct)andMMF(minimummarketablefeatures)areusedtodefinethiscoreversionoftheproduct.

Forinstance,thecoreversionofagolfcarshouldatleasthaveanengine,tires,steeringwheel, brakes, seats, and autilitybox.At the first release, even theselimitedcorefeaturesmayfulfill thebasiccustomerneedof transportationonanew golf field. The decision to add which nice-to-have features, such as cupholders, ice boxes, heatedwindshields, and sound systems, can bemade lateraccordingtocustomerfeedbackonthecoreversionofthecar.

High-priority featureson scopedocuments are thebest candidates for thecoreversionof theproduct.Medium-andlow-priorityfeaturescanbeaddedto laterreleasesaccordingtocustomerfeedbackonthecoreversion.

Thepriorityoffeaturesmaychangebasedoncustomerfeedback.Afeaturethatwas initially considered low-priority may later become a high-priority one.Similarly,aproductfeaturethatwasinitiallyconsideredahigh-priorityonemaybecomeobsoleteifitdoesn’tdeliverthedesiredvaluetocustomers.

FortheCECmobileapplicationproject,BA-Works’businessanalystsassessed

Page 23: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

the request from the marketing business unit. They marked this request as aType-A project that had enterprise-level impact on sales channels. Theywereshockedwhentheysawthat themarketingbusinessunitplannedtorelease theproductonlytwomonthslater.

SinceitwasaType-Aproject,theanalystsworkedwiththemarketingbusinessunit toprepareabusiness-case.Thedetailsofbusiness-casedocumentwereasfollows:

Page 24: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 25: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Context

Ourbusinessanalystsanalyzedwhichexistingsystemssuchas:-ERP(EnterpriseResourcePlanning),-CRM(CustomerRelationshipManagement),-CMS(ContentManagementSystem)-DealerManagementSystemthemobileapplicationneededtobeintegratedwithtodelivertheproposedfeatures.

Costvs.BenefitAnalysis

Accordingtothecostbenefitanalysis,themobileapplicationprojecthadapositiveNPV(netpresentvalue).Itwouldpaybackinlessthanthreeyears.Thispaybackperiodwasacceptableforthemarketingbusinessunit.

Page 26: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Theprojectteamalsoassessedtherisksanddefinedthemitigationstrategy.

Page 27: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 28: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

4.WhichMethodologyisBestfortheLeanApproach:WaterfallorAgile?

Page 29: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

At the strategic level, successful enterprise architecture and demandmanagement preventportfolio-levelwaste by ensuring that company resourcesare utilized for the right product development projects that support companystrategies.

Topreventwasteat tacticalandoperational levels, resourceutilizationwithinthe projects should be also optimized. This can be achieved by applying anappropriatemethodologyineveryproductdevelopmentproject.

LawofEntropy

As physics theory, everything in the universe has a bias to pass from awell-orderedstatetoadisorderedstateduetothelawofentropy.Thisisalsovalidforproduct development projects. To prevent disorder and chaos, project teamsshouldapplyamethodology.

However, some managers fall into the trap of overstandardization and try toapplythesamestandardmethodologytoalloftheirprojects.Theyevenassignshowy names such as Xagile, Waterscrum, and Scrumfall to thesemethodologies.

Since every project has different dynamics, it is better to apply a customizedmethodology that fits the specific project’s needs instead of a one-size-fits-allapproach. At a majority of companies, the most popular methodologies arewaterfallandagile.

WaterfallorAgile?

Accordingtothedialecticalmethodinphilosophy,“withinthemselvesallthingscontain internaldialecticalcontradictions thatare theprimarycauseofmotion,change, and development in the world.” Similarly, the internal contradictionsanddrawbacksofthewaterfallmethodologyhavebeenthedrivingforcebehindagileadoption.

Theleanapproachisusuallyassociatedwithagilemethodologiesmainlyduetoitsthreemanifestostatements:

Page 30: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

1.“Workingsoftwareovercomprehensivedocumentation”

In scrum, a popular agile framework, requirements are defined as short andsimple user stories (as a “role,” I want “goal”) on the product backlog by abusiness unit representative (the product owner). This minimizes the level ofdocumentationandbureaucracywitnessedinwaterfallprojects.

2.“Customercollaborationovercontractnegotiation”

Inagileprojectstheproductownerandthedevelopmentteamworkatthesamelocation,whichcreatesamorecollaborativeproductdevelopmentenvironmentcomparedtowaterfallprojects.

3-“Respondingtochangeoverfollowingaplan”:

In waterfall projects, development waits for the completion of analysis anddesignphases.Thus,inaone-yearproject,ittakesatleastfivetosixmonthsonaveragetogettotheworkingpartsofaproduct.Thislatencyindeliverycreatesanxietyforbusinessunitswhoareimpatienttosee“quick”results.Ontheotherhand,theagileteamreleasesaworkingpartoftheproductinaseriesoftwotothreeweeklong“sprints”underthecoordinationofa“scrummaster.”Theteamvelocity is adjusted iteratively by analyzing burn-down charts of previoussprints.

Agileprojects’fastdeliveryofworkingproducts,startingfromthefirstiteration,bringsconfidencetoallstakeholdersandenablesthegatheringofearlycustomerfeedback.

Atdynamicbusinessenvironmentsinwhichchangeisnottheexceptionbutthenorm, applying agile methodology is more meaningful, because waterfall haslow flexibility for changes on requirements. Any possible change to therequirementshasanimpactontheoverallanalysisanddesignartifacts.Inagileenvironments a change to the requirements has no effect on the parts of theproductthathavenotbeenanalyzedordesignedyet.

The product owner and the project team should conduct regular “groomingsessions” in agile projects. The aim of these sessions is to discuss customerfeedbackfromprevioussprintsandupdatetheproductbacklogbyremovinguserstories that no longer have a value proposition. This alsomakes agile amoreeffectivemethodologyindynamicbusinessenvironments.

Page 31: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

However, applyingagilemethodology toeverykindofproject isnotacorrectstrategy.Itisstillmoreappropriatetoproceedwithwaterfallwhen:

-theproducthasintensiveintegrationamongitscomponents;

-thecolocationofprojectteammembersisnotfeasible;

-it isnotpossible for the teammembers toworkonly for a singleproject at atime;and

-thereishighemployeeturnover,whichrunstheriskoflosingprojectknowhowincaseprojectteammembersleavethecompany.

Agileisiterativebynature.Althoughwaterfallisasequentialmethodology,itisstillpossibletomakeitmoreiterativeby

-increasingthenumberofreleases,

-benefiting from prototyping and reviewmeetings to get early feedback fromcustomers,

-minimizingthedetail levelofrequirementdocumentsbymoreeffectiveusageofdiagrams,and

-decomposing requirements into right granularity to improve understandabilityandtraceability.

Quantumvs.DeterministicModels

Einstein’s and Heisenberg’s formulations are the most dominant models forexplaining the laws of physics. Einstein did not believe in randomness(indeterminism),andhesummarizedthiswithhisfamousquotation,“AsIhavesaidsomanytimes,Goddoesn’tplaydicewiththeworld.”Ontheotherhand,Heisenberg’squantummodelisbasedontheuncertaintyprinciple,whichisalsocalledthe“principleofindeterminacy.”

Although these two theories are completely different, a physicist can still useboth tomake accurate calculations for different cases.While theymostly useEinstein’s formulations tomodelatomicparticlesmovingatvelocitiesclose tothe speed of light, they use quantum formulations to model the behavior ofsubatomicparticles.

Page 32: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

We can associate waterfall methodology with Einstein’s deterministic modelsanduseitforprojectsthatrequirebigdesignupfrontinrelativelystaticbusinessenvironments. On the other side, we can associate agile methodology withquantum theory’s indeterminism due to its success in dynamic businessenvironmentswithrandombusinessconditions.

Managersshouldnotfallintoan“either/orfallacy”byfeelingtheyhavetoselecteitherwaterfall or agile. For someprojects, including both static and dynamicconditions,evenahybridstrategycanbeformulatedthatappliesbothwaterfalland agilemethodology for different phaseswithin the same project.Waterfallcan be applied at the initial phase of the project to release high-priority, corefeatures of a product that has a complex architecture of many integratedcomponents, and agile methodology can be applied in later phases to releaseremainingmedium-andlow-priorityfeatures.

For the CEC mobile application project, our team applied a similar hybridmethodology.Waterfallwasappliedatthefirstphaseoftheproject,whichlastedtwo months. At this phase only high-priority features were developed andreleasedonacoreversionofthemobileapplication.

Page 33: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 34: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Thefirstphaseoftheprojectwasdeliveredontime,withintwomonths,andthefollowingobservationsweremaderegardingtheinitialreleaseoftheproduct:

-Amobilesaleschannelwaslaunchedbeforecompetitors.

-ThenumberofpeoplewhodownloadedtheCECmobileapplicationwasmorethanexpected.

-Thenumberof customerswhoused themobile application toviewandorderCECproductswasmorethanprojectionsonthebusiness-casedocument.

Thisway,theCECmarketingbusinessunitverifiedthatthemobileapplicationwasagoodidea.Evenwithalimitednumberoffeatures,theproductgeneratedhighvalueforCECcustomersandsatisfiedbusinessrequirements.

Basedontheseinitialresults,themarketingbusinessunitdecidedtoinitiatethesecond phase of the project to implement medium-priority features that werepredefinedonthebusiness-casedocument.

Page 35: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

In the second phase, the project team applied agilemethodology. The projectmanager started toplay the scrummaster role.Since theCECmarketing teamcouldnotallocateaseniorrepresentative,themostexperiencedbusinessanalystof the team played the role of product owner. The other business analystsbecamepartoftheagileteamtogetherwithdevelopersandsoftwaretesters.

The medium-priority features of the mobile application were developed andreleasedwithintwosprints,eachofwhichlastedthreeweeks.

Page 36: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

After analyzing the customer feedback and mobile application usage logs ofsprintsoneandtwo,themarketingbusinessunitobservedthat:

-Customers definitely checked other customers’ ratings and reviews beforebuyingaproduct.Thisnewfeaturewasalsoveryusefulforlisteningtothevoiceofthecustomer,whichwasnotpossibletogetfromthedealerchannel.

-Instead of contacting the call center, CEC customers were using the mobileapplication to track their orders. This resulted in extra savings, thanks to thereductioninoutsourcedcallcentercosts.

CMOwashappytoseethatnewlyaddedfeaturespaidbackveryquickly.Afteranalyzing usage logs and customer journey mapping studies, the marketingbusiness unit decided to add some additional features to further increase themobileapplication’sutilizationrate.

Page 37: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Thesenewfeatureswerealsoimplementedwithagilemethodologyintwomoresprints.

Page 38: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

After analyzing the customer feedback and mobile application usage logs ofsprintsthreeandfour,themarketingbusinessunitobservedthat:

Page 39: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

-TheproductfeaturethatsentcouponcodeswhencustomersconnectedtoaCECproductvia theCECmobile applicationbecameverypopular.Usedbyahighnumber of customers, it positively impacted cross-sell opportunities andcustomerloyalty.

-Customerswerenotasresponsiveasexpectedtothecontextualofferssentviathemobile application. Thiswas a disappointment for themarketing businessunit. The business unit decided to drop this feature, which was not addingremarkablevalue.

-Themarketingbusinessunitalsonoticed that somecustomerswere rating thedealerservicequalityperformanceverylow,andthiswasnegativelyimpactingother customers’ buying decision. The team decided to fix this problem asfollows:Customerswouldcontinuetoratedealerservicequalityviathemobileapplication,butthecustomer’sratingwouldnotbevisibletoothercustomers.ItwouldonlybevisibletotheCECdealermanagementteam.

Page 40: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

5.RequirementsGathering

Page 41: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

User requirements, functional requirements, nonfunctional requirements, andbusiness rules of the product should be defined consistently with businessrequirements to keep the project on track and ensure the strategic, user, andtechnicalfitnessoftheproduct.

-Userrequirements:whatcustomerneeds/goalstheproductshouldmeet

-Functionalrequirements:whatfunctionalitytheproductshouldhaveinordertomeetuserrequirements

-Nonfunctional requirements:how theproduct shouldwork in termsofqualityattributes,suchasusability,performance,privacy,andsecurity

-Businessrules:mainlytheconditions,constraints,andformulasthatdeterminehowrequirementswillbehandledbytheuserandtheproduct

Iftheseuser,functionalandnonfunctionalrequirements,andbusinessrulesarenotconsistentwithbusinessrequirements,thenprojectoutcomeswillnotdeliverthe desired value and fulfill customer needs. To mitigate this risk, businessanalysts should give highest priority to translating business needs into correctuser requirements during requirements-gatheringmeetings. They should focuson resolvingconflicts about these requirementsbeforediscussing the technicalaspectsof theproduct.Theyshouldalwayskeep inmind that “doing the rightthingisalwaysmoreimportantthandoingitright.”

Business analysts should consider conflicts among project stakeholderspositively during the requirements-gathering stage. If these conflicts are notdiscussedandresolvedatthisearlystageoftheproject,theywilllaterappearashigh-costCRs(changerequests)atthedevelopmentandtestingphases.CRsarethemainsourceofwasteatPDLCbecausethey

-can’tbeplanned,

-resultinscopecreep,

-causeanalysisparalysis,

-generatehiddencosts,

-aremostlyurgent,

Page 42: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

-havebothdirectandindirectimpactsonvariouspartsoftheproduct,and

-maybringaregression-testingburden.

Intheleanapproach,businessanalystsshouldbeawareoffactorsthatresultinCRs and try to prevent them. Themain reason for CRs is the “problems anddeficiencies in requirements-gathering, documentation, and managementprocess.”

These kinds of CRs should be prevented in a proactive way by applying thefollowing best practices throughout the requirements-gathering phase of aproductdevelopmentproject:

-Realizethatinnovationcannotbeachievedatthetechnicallevel.Innovationisamatterofformulatingsolutionsthatbestmeetuserneeds.

-During requirements-gatheringmeetings, be customer centric and ask, “Whatare customers’ needs and how will the new product meet them?” instead ofasking,“Whatshouldbethetechnicalfeaturesofthenewproduct?”

-Be open-minded, find alternative solution options, and prevent shallow“either/or”discussionsaboutproductfeatures.

-Balance the level of creative vs. critical thinking at requirement-gatheringmeetings.At thebeginningof theproject,beascreativeaspossible.Butwhenyou start detailed requirement analysis, employ critical thinking. Criticalthinking means asking the right, to-the-point questions and verifying thembeforeassumingthattheyarecorrect.

-Atthemeetings,getreadytosaynotoevengoodideasfromthebusinessunitsif these ideas are not in alignmentwith business and user requirements of theproduct.

-Although business analysts and project managers may have enough level ofbusiness and technical knowledge, technical teams should still be invited torequirements-gathering meetings to better evaluate the technical feasibility ofrequirements.

-Don’ttrytofindtheanswerstowhy(weneedtheproduct),what(theproductdoes), how (the product does), and technically how (the product works)questionsduringonesinglemeeting.For large-scaleprojects, conduct separate

Page 43: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

sessions for interviews, focus groups, and workshops if your project is not atime-sensitive,fast-trackone.

GototheGemba

-Don’t listen to the voice of the customers only from product owners andbusinessunitrepresentatives.Elicitationtechniques,suchasshadowing,shouldbeusedtoobservecustomerswhileusingtheproductsortheirprototypes.Intheleanapproach,thisisdescribedas“gotothegemba.”

Yes-Menvs.No-Men

-At requirements-gatheringmeetings, get ready todeal bothwithyes-menandno-men frombusiness units.Yes-men aremore dangerous than no-men.Theyare silent and friendly during requirements-gathering meetings but becomeaggressiveandextremelydemandinglateratuseracceptancetests.Althoughno-menareusuallyregardedastroublemakers,theyaremorehelpfulinidentifyingand resolving conflicts at the early stages of the project. Resolution of theseearlyconflictspreventswasteduetocostlychangerequestsatlaterstagesoftheproductdevelopmentproject.

Perfectionistsvs.Overlookers

-In the lean approach, requirements gathered from both perfectionist andoverlookingpeopleshouldbeanalyzedcarefully.Perfectionistsusuallyfocusondetails of low-priority product features. On the other side, overlookers maymisleadtheprojectteambyevenundermininghigh-priorityproductfeatures.

APictureIsWorthaThousandWords

-Benefit from prototyping during requirements-gathering meetings to helpparticipantsvisualizetherequirementsintheirminds.

QuantumObserverEffect

-The way of asking questions in requirements-gathering meetings is alsoimportant.Theobservereffect inquantummechanicsstates that“by theactofwatching, the observer affects the observed reality.” Similarly, duringrequirements-gatheringmeetings,askingquestions inabiasedway impacts the

Page 44: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

objectivityofanswersfromparticipants.

-At requirements-gathering meetings, giving the right answers to wrongquestions ismoredangerous thangivingwronganswers to the rightquestions.Wrong questionsmislead the team, generate conflicts,waste project time, andresultinfailure.Businessanalystsshouldpreparesimple,objective,andto-the-pointquestionsforthesemeetings.

ConflictIsaNormbutNotanException

-At requirements-gathering meetings, don’t be afraid of conflicts andnegotiationsamongparticipants.ThemoreconflictsresolvedatthisearlystagemeansfewerCRsduringtheproject.

-Try to clarify all of the issues during requirements-gatheringmeetings.Don’tpostpone them by entering into an issue database. Issue management meanspostponingproblems.

-Don’tfeeldesperateduringrequirements-gatheringmeetingswhenthenumberof conflicts increases and the problems get complicated.At those times, thinkthat the project is not rocket science like at NASA or CERN, and do notexaggerate thesesituations. Insteadofgivingupearly, remember theadviceofHenryFord:“Therearenobigproblems;therearejustalotoflittleproblems.”

-Apply the “functional decomposition” technique to divide problems intosmallerpartsandresolvethemonebyone.Whenneeded,benefitfromthe“fivewhys” technique, which is iteratively asking questions as a basis of the nextquestionuntilfindingtherootcauseofaparticularproblem.

ButterflyEffectinChaosTheory

-Whenachangerequestisreceived,analyzeitsforwardandbackwardimpactonalllevelsofrequirements.AccordingtotheButterflyEffectinChaosTheory,asmall change at one place in a complex system can result in large effectselsewhere.The formationdetailsof ahurricane canbe influencedevenby theflappingofabutterfly’swingsatadistinctlocationseveralweeksearlier.ThisisalsovalidforCRs.ACRthatisconsideredtobeminormayresultinabutterflyeffectonlotsofotherproductcomponentsandrequireabigeffort.

Page 45: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

6.RequirementsDocumentation

Page 46: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Features that customersdonot use after the release are a big sourceofwaste.Themain reason for thisproblem is the lackof customercentricityduring thetraditionalproduct-centricanalysisanddesignapproach.

Definingthedetailsofuserrequirementsbyemployingthe“usecase”techniqueinwaterfallmethodology and the “user story” technique in agilemethodologyhelpsprojectteamsbemorecustomercentric.

UseCaseTechnique:

In waterfall methodology’s use case–driven analysis, user requirements aredefinedinthreesteps:

1.Whoaretheactors?

Targetactorsaredefined.

2.Whatarethegoals(usecases)ofactors?

User requirements (usecases) correspond to thegoalsof theactors.Usecasesareshownonause-casediagram,whichalsoillustratesthehigh-levelscope.

For the CEC mobile application development project, the use case diagrambelowwasdefined:

Page 47: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

3.Howwilltheactorsachievetheirgoals?

Inwaterfallmethodology, the activitiesof actors to achieve their goals canbeshownonusecasedocuments.

Asmentioned earlier, the scope of the CECmobile application project’s firstphase includedonly“ViewandOrderaProduct“and“CompareProducts”usecases. The interaction of the CEC customers with the mobile application toachievethesegoalswasdefinedonusecasedocuments.The“ViewandOrderaProduct”usecasewasdocumentedasfollows:

Page 48: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 49: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Inuse-casedocumentation,thefollowingbestpracticesshouldbeconsidered:

Page 50: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

-Scenarios on the use case document describe the activities of actors whileachievingtheirgoals.

-Eachscenariostep(activity)correspondstoafunctionalrequirement.

While applying the use-case technique, there may be confusion about thedifferencebetweenausecaseandafunctionalrequirement.Actuallyitisquitesimple. Each use case represents a particular goal of an actor, whereas theactivitiestoachievethatgoalarefunctionalrequirements.

Let’s explain this relationship with an analogy: If a bottle is considered aproduct,“drinkingwater”isausecase,sinceitisagoalofanactorinusingthebottle. But “opening the bottle cap” is not a use case, because it is not aparticulargoaloftheactor.Peopledon’tbuybottlestoopenandclosetheircaps.Opening the bottle cap is just a functional requirement to reach the goal of“drinkingwater.”

Similarly “View and Order a Product” is a use case for the CEC mobileapplication, whereas “category selection” is one of the several functionalrequirementstoachievethatspecificusecase.

-Separatemain,alternative,andexceptionscenariosoftheusecase.

Themainscenarioonausecasedocumentrepresents thepositiveflow(happypath)ofactivitiestoachievethegoaloftheactorinnormalconditions.

Alternativescenariosdefineotherpossiblewaysofachievingthesamegoal.

Exception scenarios define the activities of the user in exceptional and errorconditions.

Forthe“ViewandOrderaProduct”usecaseintheCECmobileapplication,iffinding an item by navigating through categories is described in the mainscenario, then the discrete activities needed to find that item by using the“Search” functionality should be defined within an alternative scenario. Theinteraction between the customer and the CEC mobile application when thecustomer attempts to order an out-of-stock item should be defined as anexceptionscenario.

-Defineexceptionscenariosseparatelyfromalternativescenarios.

Alternative scenarios may include some nice-to-have conditions that can be

Page 51: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

postponeduntilfuturereleases,incasethereislatencyintheproject.However,exceptionscenariosincludeerrorconditions,andtheyhavetobeimplementedinanycase.

-Usecasedocumentsaimtoanswerwhat(functionalityneededinordertomeetuser requirements) and how (nonfunctional requirements and business rules)questions.

Clarifying the technicallyhow (inner technicaldynamics)question isnotausecasedocument’sobjective.Therefore,don’tincludetechnicaldetailsonusecasedocuments. According to the “just in time” principle of the lean approach,technical requirements should be defined later in a separate technical designdocument.

-Defineusecasescenarioswiththeusers’pointofview,butdon’tincludeuserinterface details. Those details are defined later on prototypes and in userinterfaceannotationsbasedonusecasescenariodefinitions.

Forexample,“customerselectscategorybyclickingbuttonsatthemiddleofthescreen”isawrongscenarioactivitydefinition.“Customerselectsacategory”isjustenough.

-Inadditiontofunctionalrequirements,alsodefinenonfunctionalrequirements,businessrules,andassumptionsonusecasedocuments.

-Definebusinessrulesinaparametricway.

Thiswill let theprojectteameasilydesign,develop,andchangebusinessruleswhenneeded.

Forexample,inthe“ViewandOrderaProduct”usecase,“Userisnotifiedwitha message indicating that 1 percent commission will be charged for expressdeliveries” is a wrong functional requirement definition. Instead it should bedefined as “User is notifiedwith amessage indicating that a commission ratewill be charged for express deliveries (BR1).” Business rules in this scenarioshouldbedefinedinthebusinessrulessectionofthesameusecasedocument.Thebusinessruleinthisexampleshouldbedefinedasfollows:

BR1:ExpressDeliveryCommission=1percent

-Definenonfunctionalrequirements,suchasusability,performance,andprivacy,

Page 52: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

foreachusecaseinaverifiable(testable)way.

Forexample,“Afterthecustomerconfirmsthepayment,anOrderConfirmationReport should be displayed fast” is not a correct performance requirementdefinition.Itshouldbedefinedas“Afterthecustomerconfirmsthepayment,anOrderConfirmationReportshouldbedisplayedwithintwoseconds.”

-Limitassumptionstotheconditionsinwhichtheuserhasnocontrol.

Forexample,“ProductavailabilitydatareceivedfromtheERPinventorymoduleis up to date and accurate”may be an assumption for the “View andOrder aProduct” use case.But “the items thatwill be ordered by the customer are instock” isnotacorrectassumption.Thebehaviorof thecustomerand theCECmobileapplication,incasethecustomerattemptstoorderanout-of-stockitem,shouldbedefinedasanexceptionscenarioontheusecasedocument.Otherwiseunclarified assumptions will create many issues at the user interface design,technicaldesign,anddevelopmentstagesandresult inwastedue tounplannedwork.

-Benefitfromflowchartstovisualizeusecasescenarios.

In history, people first used drawings to communicatewith one another.Evenaftertheinventionofletters,theycontinuedtousedrawingsasaneasywayofexpressing themselves. Similarly, using diagrams such as flow charts is aneffectivewayofvisualizingusecasescenariosandclarifyingtheambiguitiesinnarrativerequirementdefinitionsonplaintext,usecasedocuments

Flow charts are useful for modeling and describing work flows with simplediagramming conventions. A flow chart should be created for each use case.Each branch on a flow chart represents the main, alternative, or exceptionscenarioofausecase.

Theflowchartbelowrepresentsthe“ViewandOrderaProduct”usecaseoftheCEC mobile application. The branches on the chart show scenarios of thatspecificusecase.

Page 53: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

UserStoryTechnique

Unlike waterfall, agile methodology focuses on “working products overcomprehensivedocumentation.”

Inscrum,requirementsaredefinedasshortandsimpleuserstories(Asa“role,”Iwant“goal”)inparallelwiththeabovemanifestostatement.

Asmentionedearlier,agilescrummethodologywasappliedatthesecondphaseoftheCECmobileapplicationproject.Insteadofdetailedusecasedocuments,simpleuserstoriesweredefinedatthisphase.

Some of the user stories included in the product backlog of the CECmobileapplicationprojectwereasfollows:

-Asauser, IcancommentonCECproducts so thatothercustomerscan learnaboutmyexperience.

-As a user, I can rate CEC products so that other users can benefit frommyopinioninmakingtheirbuyingdecisions.

-As a user, I can see the comments and ratings of customers posted via themobile application, also on the CEC web page, so that I can make a betterdecisioninproductselection.

-Asauser,IcansearchfortheaddressofthenearestCECdealerstoressothatIcangoandviewtheproductsIplantobuy.

-Asauser, Ican track thestatusofanorderso that Icanarrangemytimefordeliveryoftheproducttomyhome.

-Asauser,IcancancelmyorderonthemobileapplicationsothatIdon’thave

Page 54: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

tocontactthecallcenter.

-Asauser,IcangetcampaignoffersonthemobileapplicationwhenIamnearadealer location so I canvisit the store andview theproductwithadiscountedprice.

-As a user, I can get discount couponswhen I connect to a CEC product viamobileapplicationsothatIcanusethemtopaylessformylaterpurchases.

-Asauser,IcanlogintotheCECmobileapplicationalsowithmysocialmediaaccountssothatIcaneasilypostinformationaboutCECproducts.

Userstoriesare lightweightcompared tousecases.Tomakeuserstoriesmorespecificanddescriptiveforthedevelopmentteam,acceptancecriteriashouldbedefined for each user story. Acceptance criteria should also includenonfunctionalrequirementsandbusinessrulesassociatedwitheachuserstory.

SomeoftheacceptancecriteriadefinedfortheCECmobileapplicationprojectwereasfollows:

Page 55: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 56: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 57: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 58: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 59: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

DoWeStillNeedBusinessAnalystsinAgileProjects?

Page 60: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Userstoriesaredefinedandprioritizedontheproductbacklogbyabusinessunitrepresentative (product owner). He or she is the voice of the customer. Intheoretical formulation there is no need for business analysts or their detailedrequirementsdocumentsbecause theproductownerand theagiledevelopmentteam,whichconsistsofdevelopersandQA(qualityassurance)specialists,worktogetheratthesamelocationunderthecoordinationofascrummaster.

However, in practice there are some difficulties in realizing this theoreticalframework.

Productowners(lacking technicalknowledge)havedifficulties inspeaking thesame languagewith technical teams (with limited or no business knowledge).Thismakesithardertotranslatebusinessneedsintorequirements.

Additionally,productownerscanrarelyspendenoughtimewiththeagileteamduring their own department’s busy times, and this makes the situation evenmoredifficult.

To prevent these problems, business analysts have started to play the productownerroleorhavebeeninvolvedinthetechnicalteamthatusedtobecomposedofonlydevelopersandQAspecialists.

Whetheritiswaterfalloragilemethodology,thefollowingbestpracticesshouldbeappliedinrequirementsdocumentationtopreventwasteandensurethebestcommunicationamongprojectstakeholders:

LeanPrincipleof“JustEnough”

One of themain goals of the lean approach is eliminatingwaste by reducingwork-in-process inventory (WIP). At PDLC unnecessarily long analysis anddesign documents represent WIP. To minimize WIP and eliminate waste,analysisanddesigndocumentsshouldbe“justenough.”Theyshouldbeconcisewithout information overload. They should include only what is absolutelynecessary.

As expressed in the phrase “A picture is worth a thousand words,” businessanalysisdiagrams,suchasusecasediagrams,flowcharts,andcontextdiagrams,shouldbeusedtodecreasetheinformationoverloadonrequirementsdocuments.

Attherequirementsdocumentationphase,theobjectiveshouldnotbetoproducefancydocumentsandelegantdiagrams thatwon’tbe readbyanypersonother

Page 61: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

than the business analyst who prepared it. Instead, the objective should be tocreate products that best meet the business and customer needs by usingrequirementsdocumentsanddiagramsastools.

We need requirements documents during the project to translate business andcustomerneeds into requirements fordevelopers’bestunderstanding,andafterthe project to use as a requirements repository during futureenhancement/modificationofproducts.

Thedetaillevelofdocumentsshouldbecalibratedaccordingtospecificprojectneedsandconditionsastobestsatisfytheaboveobjectives.

If the detail level of the documents is too low, there is a risk of incompleterequirementsdefinition.Inthiscasetechnicalteamshavetoguessaboutproductfeatures.Theybuildproductsthatmisscriticalrequirements,andthistriggersavicious cycle of CRs (change requests). And sometimes they build in extrafeatures that are not included in the requirements documents, thinking thatcustomerswillbedelightedtoseethem.Thissituationiscalled“goldplating.”BothCRsandgoldplatingarefactorsthatresultinscopecreepandthuswasteduringtheproject.

Indailylifetherewouldbechaosiftherewerenogoverningrules.Forexample,although traffic lights seem to slow us down, trafficwould be lockedwithoutthem.Requirementdocumentsarelikethetrafficlightsinbigcities.Ifwedon’tuse them, theproject starts fast but is lockedat some later stage.However, insmallcitieswedon’tneedtolocatetrafficlightseverywhere.Similarly,insmall-scaleprojectswedon’thavetouseverydetailedrequirementsdocuments.

When teammembers are atdiscrete locations, thismay limit the collaborationamongprojectstakeholders.Thesameproblemmaybeobservedonoutsourcedprojects.Inthesesituations,thedetaillevelofdocumentsshouldbeincreasedtoensureclarityandcorrectnessofrequirements.

Thedocumentspreparedduringtheanalysisanddesignphaseoftheprojectalsoserveasarequirementsrepository.Thismakesthedeploymentoffutureproductenhancements and modifications much easier and faster. Thus requirementdocumentsshouldbekeptupdatedevenaftertheprojecttoserveasarepositoryofrequirementswhenneededduringfuturemodificationsof theproducts.Thiswill save a lot of time for the project team responsible for laterenhancement/modificationworkandpreventaconsiderableamountofwastein

Page 62: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

thefuture.

LeanPrincipleof“JustinTime”

AtPDLC,

-theanswerofthe“technicallyhow”question(systemrequirements)dependsontheanswerof

-the “how” question (nonfunctional requirements and business rules), whichdependsontheanswerof

-the “what” question (user requirements, functional requirements), whichdependsontheanswerof

-the“why”question(businessrequirements).

Accordingtothe“JustinTime”principleintheleanapproach,thesequestionsshouldbeansweredinorderandshouldbedefinedonseparatedocuments.

First, the business requirements and user requirements should be defined andlisted on business-case or vision and scope documents; then functionalrequirements, nonfunctional requirements, and business rules should bedocumented on use case documents or user stories, depending on the selectedmethodology. Then system requirements should be documented on technicaldesigndocuments.Definingtheminasinglerequirementsdocumentwillcreatealotofcomplexityandconfusionforbusinessunitsandtechnicalteams.

Page 63: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

7.UXDesignandUsability

Page 64: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Thebestuserexperience(UX)onaproductcanbeachievedonlyifusabilityisalsopositionedasamust-have requirement throughout theanalysisanddesignprocess,inadditiontofunctionalityandvisuallyaestheticconcerns.

Usabilityisthecriterionthatdetermineshoweasyaproductisforitsusers.Evenifit isveryelegantandhasgreatfunctionality,aproductcannotfullymeettheneedsofitsusersunlessitisusable.Sounusedfeaturesoftheproductscreateahugeamountofwaste.

GaudiApproach

Throughoutthehistoryofarchitecturedesign,Gaudihasbeenthemostfamousarchitect with his user-centered architecture design approach. During hischildhood,Gaudisufferedfrompoorhealth.Thissituationpreventedhimfromgoing to school, and he spentmost of his time in nature.His observations ofnatureinspiredhisdesignapproach,whichcanbesummarizedasfollows:“Thegreatbookalwaysopen,andwhichweshouldmakeanefforttoread,isthatofNature.” Using this philosophy he designed buildings with “organic style,”whichthenbecameanimportantstandardinarchitecture.

HumanizationofProducts

Another man revolutionized the high-tech industry in a similar way. Bypositioningusersatthecenteroftheanalysisanddesignprocess,SteveJobsledtheinnovationofthemostusableconsumerelectronicsproductsever.

Heachievedcreatingnatural-bornusersofhisproducts.Evenkidscanusehiscompany’smobiledeviceswithgestures similar to theirnaturalbehavior.Thisnew design approach made his company the best performer in the high-techindustry.

After the success of this approach, it was realized that the humanization ofproductsisnotnecessarilyachievedbyanthropomorphicfeaturesbutmainlybyensuringusability.

BuildingUserInterfacesaroundUsers

Page 65: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

A leanUXdesign approach that is both user centered and iterative should beappliedtoensureusabilityofanewproduct.

A.IdentifyUserProfiles

“Designing foreverybody” isnota feasibleandeffective strategy in termsofusability. Interfacesof aproduct areusable if theyareagood fit for itsusers.Thusaproduct’suserinterfacedesignshouldbebasedontheprofileofitstargetusergroups.Profilingcanbedonebasedondiverseusercharacteristics,suchas:

-age,

-gender,

-education,

-computerusecomfortlevel,

-smartphonecomfortlevel,and

-businessbackground.

For the CEC mobile application project, the profiling of customers was asfollows:

Page 66: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

An effective way to understand user profiles during requirements-gatheringsessions is to ask users their opinions about the existing products. Users’comments can be interpreted to understand their own capabilities andweaknesses.ThisremindsusofaquotationbythefamousphilosopherSpinoza:“IfPierretellssomethingaboutPaul,welearnmoreaboutPierrethanwelearnaboutPaul.”

In addition to interviews and focus groupmeetings with users, UX designersshouldalsoconductfield-analysistechniques—suchasshadowingandusertaskanalysis—to observe users in their own context and then profile themaccordingly.

B.DefinePersonasandTheirMentalModels

Another importantaspectofusercentricity isemotionaldesign.Humanbeingsjudge products based on their left brains’ logical and right brains’ emotionalcapabilities. And most of the time, emotion is the main criterion in theirjudgmentstobuyaproduct.

In alignment with their emotions, users first create a mental model of theproducts they use. Thismodel guides them throughout theirwhole experiencewiththeproduct.Therefore,userinterfacedesignsshouldbebasedonthementalmodelofusersratherthanofdesigners.

Personas, which are representative imaginary characters, are the best way todefine the mental models of diverse user profiles and predict their expectedinteractionwiththeproductandbehavioronuserinterfaces.Althoughtherecanbeseveraluserprofilesforaproduct,UXdesignersshouldlimitthenumberofpersonas to three (or atmost four in extremecases) toprevent falling into thetrapof“designingforeverybody.”Apersonadescriptionshouldincludeaname,aphoto,demographicinformation,andascenariosection.

FortheCECmobileapplicationproject,theUXteamdefinedthefollowingtwopersonasafteranalyzinguserprofilesandworkingwiththemarketingbusinessunit.

Page 67: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 68: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

C.InteractionDesign

IntheleanUXdesignapproach,meetinguserneedswithaminimumnumberofstepsontheproduct’suserinterfacesishighlyappreciated.Thiscanbeachievedbyagoodinteractiondesign.

“ArchitectureBeginsWhereEngineeringEnds”—WalterGropius

Ifwelldefined, flowchartsvisualizingusecase scenarios formaperfectbasisfordesigninteractionofuserswiththeproduct.

Duringinteractiondesign,boxesonthebranchesoftheflowchartaregroupedwithin containers. These containers (dashed boxes) become a primary user-interface window, a dialogue box, or a message box. Or several containerscombineandformasingleuser interface.Linksbetweenflowchartcontainersbecomenavigationelements,suchaslinks.Thismethod,whichismainlybasedonthegroupingofrequirements,mitigatestheriskofmissinganyfunctionality

Page 69: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

onuserinterfacesoftheproduct.Italsopreventsmismatchbetweentheflowofusecasescenariosandtheflowofuserinterfaces,andensuresusability.

For theCECmobile application project, flow chartswere used for interactiondesignasfollows:

D.InformationArchitecture

User interfaces of products are composed not only of functional requirements(tasks)butalsoofcontentrequirements.

Page 70: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Therefore, in parallel to interaction design (based on functional requirements),the information architecture (based on content requirements) should also bedesigned. Themain objective of information architecture design is to identifycontent requirements, define content categories, and finalize the navigationstructuresofaproduct’suserinterfacesbyusingtechniquessuchascardsortingandwireframes.

Intheleanapproach,thecontentontheuserinterfacesofaproductshouldhavetwomainattributes:

1.Concise

-Havestatementsthatareshortandtothepoint

-Leavenoroomformisinterpretation

-Havecontent that issimpleandexpressedwithaminimumnumberofwords.This quotation fromMark Twain describes this situation very well: “I didn’thavetimetowriteashortletter,soIwrotealongoneinstead.”

2.Useful

-The content on user interfaces should remove the friction of productwith itsusers. User interfaces should speak the language of users, not the technicalteams.

-Ratherthanofferingaone-size-fits-allapproach,thecontentshouldaddresstheinformationneedsoftargetpersonas.Personarepresentativesshouldfeelthatthecontentontheproduct’suserinterfacesiscreatedespeciallyforthem.

-Content should have clear links and CTAs (call to actions) that help usersnavigateintuitivelywithouttoomuchthinking.

Card-Sorting

Ifcontent isnotgroupedcorrectly,userswillhavedifficultyfindingwhat theyare looking for on the product’s user interfaces. This is a common type ofusabilitydefect.

Card-sorting is an effective information architecture technique to prevent this

Page 71: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

risk.Itisusedtocategorizecontent.

Inthecard-sortingtechnique,contentitemsarewrittenoncards,anduserswhorepresentpersonasareaskedtogrouptheseitems.

By using a card-sorting study, theCECmobile application’s product categorystructurewasdefinedasfollows:

E.UserInterfaceDesign

UXdesignersconvertinteractiondesignsandinformationarchitecturesintouserinterfacesofproductsbyapplyingUXdesignandusabilityprinciples.

Even themost experienceddesigners can’t produce theoptimumdesign at thefirst trial. Good design is a result of several iterations. Iteration is a cycle ofdoingsomething,testingit,improvingit,andretestingit.

Making iterations on the final product is a very costly approach. Because foreveryiteration,thetechnicalcomponentsoftheproducthavetobechangedandretested,whereaschangingtheprototypeismucheasierandfastercomparedtochangingthefinalproduct.

In the lean approach, the project team and customers should frequently cometogether and evaluate the functionality and usability of the product early onprototypes.

Page 72: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Recentprototypingtoolsallowmockinguptheproductsandsimulatingtheminan interactive way. They allow user actions, such as navigating betweeninterfaces,selectingoptions,andgettingnotificationsbyerrormessages.Thankstotheseinteractivefeatures,bothfunctionality-andusability-relateddefectscanbe found and fixed at the early stages of the projectwithoutwaiting for useracceptancetestsonthefinalproduct.

Bythis iterativeapproach,ahighnumberofCRscanbeprevented.Alsoearlydetectionofdefects,withoutwaiting for lateuser-acceptance tests, reduces thecostoffixingthemandeliminateswaste.

Intheleanapproach,prototypesarealsoconsideredwork-in-processinventory.Thus, instead of mocking up every user interface and creating waste, UXdesigners shouldcreate theprototypesofuser interfacescorrespondingonly tothemostfrequentlyused,high-priorityfeatures.

For theCECmobile application project, theBA-Works teamonlymocked upuserinterfacesofthehigh-priorityproductfeaturesthatweredevelopedwiththewaterfall approach at the first phase of the project. To achieve simplicity, themobile application’s user interfaces included everything users needed andnothingtheydidn’t.

Having interaction designs based on well-prepared use cases and flow chartsmade it easy for theproject team to createprototypesofhigh-priority featuresthat made up the core version of the product. The team detected and fixedfunctionality-andusability-relateddefectsearlyontheprototypebeforereleasingitinthemarket.ThispreventedaconsiderableamountofwasteduetopotentialCRs.

Page 73: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

DoWeNeedPrototypesinAgileProjects?

Asmentionedearlier,agilemethodologywasappliedatthesecondphaseoftheCECmobile application project. TominimizeWIP inventory, our teamdidn’tprototype user stories. Instead working parts of the mobile applicationcorrespondingtouserstorieswereusedforfunctionalandusabilitytesting.

For agile projects, if user stories have the right level of granularity and areatomic, working parts of the product can be developed quickly and used for

Page 74: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

functionalandusabilitytestinginsteadofspendingextratimeforprototyping.

Picasso-PerfectDesigns

During prototyping, UX designers and business analysts may hesitate whenconsidering whether to behave like a craftsman or an artist. Until theRenaissance,themajorityofarchitectsdesignedtheirartifactswithacraftsmanapproach.Aestheticswerestill important forarchitects,but theirmainconcernwas designing buildings, bridges, and fountains that bestmet the needs of thepublic. After the freedom and creativity impact of the Renaissance, architectsstarted to behave more like artists and focused on designing more aestheticpieces.

Instead of trying to create Picasso-perfect designs with an artistic approach,businessanalystsandUXdesignersshouldalwaysbehavelikecraftsmenduringprototyping.Theyshouldfocusonmeetingthefunctionalneedsofcustomersinthemostusableway,leavingaestheticconcernstovisualdesigners.Insummarytheyshouldcreateprototypesthatmainlyshowhowtheproduct’suserinterfaceswillinteractwithuserswithoutitsvisualbellsandwhistles.

LessisMuchMoreintheLeanApproach

With the leanapproach,user interfacesofproducts shouldbedesigned simpleenough to leave no need for learning how to use the product. The best userinterfacesaresimplisticandintuitiveones,onwhichuserscaneasilyfindwhattheyarelookingforandcompletetheirtaskswithminimumeffortanderror.

Ontheoppositeside,busyandnoisyinterfacesmaketheexperiencecomplicatedforusers.Thiskindofdesigncanbeeasilycreatedbydistributingthefunctionalspecs randomly on different parts of user interfaces without toomuch designthinking.

Legendary soccer player Johan Cruyff once said, “Football is simple. Butnothing ismoredifficult thanplaying simple football.”Similarly, it isnot thateasytocreatesimplisticandintuitiveuser interfacedesigns.Simplisticdesignsrequireextratimeandeffort.

The secret to achieving simplicity in design is best explained in the quotationfrom famous novelist Antoine de Saint Exupery: “A designer knows he hasachieved perfection not when there is nothing left to add, but when there isnothinglefttotakeaway.”

Page 75: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

However, in simplifying user interfaces, an Einstein quotation should also berememberedtopreventtheriskoffalsesimplicity:“Everythingshouldbemadeas simple as possible, but not simpler.” The unnecessary parts of the userinterface should be removed to make the interfaces simpler, unless removingthesepartsclearsawayanyproductfunctionality.

CustomerJourneyMapping

FortheCECmobileapplicationproject,ourteamappliedacustomerexperienceevaluationtechniquecalledcustomerjourneymappinginadditiontotraditionalusabilitytestingmethods.

Customer journeymappingwas an effective tool to visualize and evaluate theend-to-end experience of CEC customers at different touch points. From thecustomers’ownperspective,theirexperience,emotions,andsatisfactionlevelateachpartofthejourneywerevisualized.

Page 76: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Inaddition toexploring improvementareas for interactionchannels, this studyalsohelpedtheteamdeterminewhetherdesiredvaluewascreatedforcustomersateachtouchpoint.

Forinstance,atthesecondphaseoftheproject,thefollowingadditionalfeatureswereidentifiedasanoutcomeofthecustomerjourneymappingstudy:

-Customers shouldbeable to rateandcommentondealer servicequalityafterdeliveryandsetupoftheproducts.

-CommentsandratingsofcustomersaboutCECproductsthatarepostedviathemobileapplicationshouldbealsodisplayedonthewebpage.

Page 77: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

8.TechnicalDesignandDevOps

Page 78: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

RefactoringandToleranceforFutureChanges

Due to the iterativenatureof the leanapproach, the technicalarchitectureofaproductshouldallowrevisionswithnewandupdatedfeaturesatlaterreleases.

Duringiterativedevelopment,iftheproducthasintensiveintegrationamongitscomponentsthefollowinghappens:

TheteamdeliversproductpartsAandBwithoutanymajorproblemsat initialiterations.Nevertheless,theteamrealizesthatithastomakechangestopartsAandBwhileworkingonpartCsinceithasintegrationpointswiththoseparts.Inother words, A and B have to be refactored although they have already beenreleased.

Refactoring means changing the existing technical architecture of a productwithout changing its behavior, and it is always harder than developing fromscratch.Theseback-and-forthmoveswithchallenging refactoringeffortsmakethe build and delivery of the product with integrated components even moredifficultatlateriterations.

SpaghettiArchitectures

These frequent refactoring efforts necessitate excellent architecture design anddevelopmentskillswithinthetechnicalteam.Whethertheselectedmethodologyis agile or waterfall, architects should formulate a highly flexible technicalarchitecturedesign.Otherwise thearchitecturewillbemore likespaghettiwithadditionsandupdatesatfollowingiterations.Thiswillresultinafragileproductwithperformance,security,predictability,andreliabilityproblems.

FlexibleDataModels

Tobuildahighly flexible technicalarchitecture, thedatamodelof theproductshould be parametric and flexible. This way excessive data migration andconversionneeds,due tonew transactional and reporting requirements, canbeprevented.

Duringtherequirements-gatheringphaseoftheCECmobileapplicationproject,

Page 79: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

theBA-Worksteamdefinedthereportingrequirements.Theyincluded:

-Shareofmobilechannelintotalsalesrevenue

-Mobilechannelsalesrevenuebydealer

-Mobilechannelsalesrevenuebyproductcategory

-Mobilechannelsalesrevenuebyproduct

-Conversion rate showing howmany customers ordered a product when theyusedthemobileapplication

-Effectiveness of contextual campaign notifications displayed on the mobileapplication.

Tocreateaflexibletechnicalarchitecture,BA-WorksbusinessanalystsconsideredalltransactionalandreportingneedsfortheCECmobileapplicationwhendesigningitsdatamodel,whichisshownbelow.

PerformanceandReliability

Page 80: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

In the leanapproach, theeleganceofaproduct isnotonly limitedto itsvisualaspects. An elegant product is one that proposes maximum value for itscustomerswiththehighestlevelofreliabilityandperformance.Themajorfactorthatmakesaproductfragileisitstechnicalcomplexity.Thisisusuallyaresultofembedding an excessive number of features into a product that has limitedhardwarecapacity.

Oneof thesolutionsfor thisproblemis tobuildanopen technicalarchitecturethatallowstheproducttocommunicatewithotherproductsbytransmittingdatabetween them and sharing their complementary features. This way, a singleproductdoesnothavetoincludeall thosefeatureswithinit.Thiskindofopentechnical architecture is the main driver behind wearable technologies’capabilitiesthatarebeyondtheirowncapacity.

Forinstance,usersofasimple,wearablestepcountercanalsomanagetheirdietandpersonal trainingprogramsviaitsmobile interfacesbyconnectingtootherproductssuchaselectronicscalesandfitnessdevices.

BigData

In time thedatageneratedbyproductsmay reach to abig scale.This levelofdatacan’tbestoredwithinthemduetolimitedhardwarecapacity.Toovercomethischallenge,thedatacanbestoredandmanagedonthecloud.However,thiswillonlycreatedata-levelwasteunlesscompaniesutilizebigdatatechnologiestogeneratevaluableinsightsforusersoftheirproducts.

For instance, thewearable stepcountersmentionedearlierprovidehelpful andmotivatinginsights,suchascomparingtheuser’sactivityanddietstatisticswithotherusers’ results.Theyalsodo real-timeanalysisof theuser’sdailyactivityand diet data and send notifications in case they can’t fulfill the target levels.Suchbigdatainsightsenrichthevaluepropositionoftheseproductsfrombeingsimplestepcounterstohealthylifeassistants.

DevOps

Duetotheiterativenatureoftheleanapproach,theproductgoesliveinmultiplereleases.Sometimestheproductsdevelopedwithinplannedtimeframescannotbereleasedontimebecauseofdeploymentproblems.

Page 81: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

To mitigate deployment risks, such as latencies, high failure rates, and longfixingandrecovery times,operations teamsshouldstartworking togetherwithtechnical teamsduring thedesignanddevelopmentof theproductsandalwaysbesynchronizedwith them.Otherwisedeploymentwillalwaysbeabottleneckandcreateoperational-levelwasteateveryreleaseoftheproduct.

Page 82: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

9.QualityAssuranceandTesting

Page 83: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Intheleanapproach,productdefectsresultinquality-levelwasteduetothetimeandresourcesspenttofind,fix,andretestthem.

To eliminate this kind of waste, principles of global QA and testingorganizations, such as ISTQB® (International Software TestingQualificationsBoard),shouldbeappliedwithintheproductdevelopmentlifecycle:

Testingshowspresenceofdefects.

Testing shows the presence of defects but cannot prove zero defects. Testingefforts reduce the number of undiscovered defects on the product but cannotclaimzerodefects.

In the lean approach, the balance between time tomarket and product qualityshould bewell established.Although not desired, a productmay even go livewith low-prioritydefects incase time tomarket ishighlycritical.Thisusuallyhappensatthefirstiterationofaprojectinordertoreleaseaproductearlierthancompetitors.Thesedefectscanthenbefixedatlateriterations.

Exhaustivetestingisimpossible.

Testingeverysinglepartofaproduct isnotpossibledue to timeandresourcelimitations.Intheleanapproach,testingeffortsshouldfocusonhigh-riskareasinstead of exhaustive testing. Risk prioritization should be done according topotential impact and likelihood levels. This way, the waste due to excessivetestingeffortscanbeprevented.

Page 84: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

For most of the projects, requirement documents are used as a basis for testcases. However, test cases should not only contain positive scenarios onrequirementdocuments; they shouldalsocovernegative test conditions.Thesenegative test conditions can be identified by applying risk-based testingtechniques,suchasFMEA(FailureModeandEffectAnalysis).

Applyingblack-boxtesttechniques,suchasequivalencepartitioning,boundaryvalue, and combinatorial analysis, helps to achieve enough test coveragewithminimumtestdata.Thesetechniquespreventwastebyeliminatingtheneedforexcessivetestdata.

Earlytesting

Theproductdevelopmentlifecycleislikeariverwithrequirementsatitssource.Ifyoucan’tcleantheriveratitssource,youwillhaveadirtyriverflowingdownthe hill. A reactive rather than a proactive approach to clean the river willincreasethecostsandrisksexponentially.

Due to the gravity of this situation, quality assurance teams should be moreproactiveandstart testingasearlyaspossibleduring theproductdevelopmentlifecycle.Resolutionofearlydefectspreventswasteduetocostlyfixesatlaterstages.Withoutwaitingforthedevelopmentofthefinalproduct,testingshouldbe started early by reviews on requirement documents and user tests on

Page 85: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

prototypes.Bydoingthisbothfunctionality-andusability-relateddefectscanbeeasilyfoundandfixedattheearlyphasesoftheproject.

Pesticideparadox

Ifthesamekindsoftestsarerepeatedagainandagain,thesamesetoftestcaseswill no longer help to find any newdefects on the product.To overcome this“pesticide paradox,” the test cases should be regularly reviewed and updated.Thusthewasteduetoineffectivetestingeffortswillbeprevented.

Toensureenoughcoverage,QAteamsshould form the testbasisaccording torequirementsandbusinessrulesonanalysisdocumentsandcombinethemwithrisk-basedtestconditions.

DuringphaseoneoftheCECmobileapplicationproject,the“ViewandOrderaProduct” test case was defined as follows based on main, alternative, andexceptionscenariosoftherelevantusecasedocument:

Page 86: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 87: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 88: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

As shown on the above example, use case documents that have detailedscenariosformagoodbasisfortestcases.Whenagilemethodologyisapplied,however, user stories and their acceptance criteria do not have that level ofdetail.Toensureenoughtestcoverage,QAteamsonagileprojectsshouldworkinhighcollaborationwithproductownersandotherbusinessunitrepresentativesduringthetests.

AutomatedTesting

In lean’s iterative approach, addingnewcomponents to a liveproductwithoutimpacting itsalready releasedparts is likechanging the tireofacarwhile it’smoving.

This iterativedevelopment approach requires comprehensive regression testingoftheproductcomponentsthatwerealreadyreleasedinpreviousiterations.Toensureenough testcoverage, thepartswithbothdirectand indirect integrationpoints should be retested. This brings a huge amount of extra testing effort.Testingthesamecomponentsmanuallyandrepetitivelyisbothtime-consumingandimpractical.Tomakethisprocessmoreefficient,automatedregressiontestsuitescanbecreated.

However, automation itself is a challenging project. Project managers shouldconsiderthetimeneededtoimplementautomationtoolsasaseparateriskitemineveryproject.Theyshouldnotuseanautomationtoolfor thefirst timeinatime-sensitive, high-priority project. The team should focus on the project,

Page 89: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

insteadofallocatingits limitedtimefor tool implementation.Projectmanagersshouldrememberthatuppermanagementalwaystakesaccountofthescorebutnothowtheteamplayedduringthegame.

Inanautomated regression-testingprocess, testproceduresarecapturedas testscriptsatthefirsttestcycleandthenrunautomaticallyinfollowingtestcycles.However, test automation is not amagicwayof findingdefects bypressing asinglebutton.Mostofthetimetechnicalproblemsariseontestautomationtoolsduringtestscriptgeneration.Fixingtheseproblemsrequiresadvancedtechnicalskills. For this reason test automation should always be the responsibility oftechnicalQAteamsratherthanbusinessanalysts.

In some circumstancesmanual testing becomesmore efficient than automatedtesting;ittakesmuchmoretimetogenerateautomatedtestscriptscomparedtorunningtestcasesmanually.Especiallyintime-sensitive,fast-trackprojects,thisresultsinaweirdsituationofcodingaroundbugsinsteadoffindingandfixingthem.ProjectmanagersandQAmanagersshouldconsiderthisissueasaprojectrisk. They should mitigate this risk by determining the right level of testautomation.

Shelfware

Inrecentyears,wehavestartedtoseeadifferent“ware”category(likehardwareand software). This category is called shelfware. Shelfware represents theautomationsoftwarethatsitsontheshelvesofthecompanywithoutbeingusedbyanysingleperson.

Shelfwarecausesahugeamountoftool-levelwaste.Atsomepubliccompanies,high license and support costs paid for useless shelfware has even become anissueinvestigatedduringinternalaudits.

Topreventshelfwaresituation,managersshouldknowthatautomationtoolsarewizards but not magicians. They have limits. They can only help the projectteamdoitsworkinamoreconvenientwaybyautomatingsomeofthetasks,butnot all of them. If the organization’sQA processmaturity is at a good level,automation makes it better; otherwise, automation may even make it worse.HencemanagersshouldfirstfocusonimprovingtheirQAandtestingskillsandthengivethego-aheadfortheautomationinitiative.Iftheteamhasonlylimited

Page 90: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

knowledge of test methods and techniques, automation will only bring extraproblemsratherthanbenefits.

UATIstheLastFilteringPointofDefects.

Evenwith theexistenceofaseparateQAteam,businessanalystsshouldbe inchargeofcoordinatingandguidingbusinessunitsduringUAT(useracceptancetests). UAT is the final stage for validating requirements and ensuring thefulfillmentofbusinessneedsofthenewproduct.IncaseUATisnotconductedeffectively, end userswill find defects after the release, and thiswill result inmoneyandreputationloss.

To increase the effectiveness of UAT, users should first conduct experience-basedtestswithoutrunninganytestcases.AfterwardanotherUATcycleshouldbe organized to ensure enough test coverage by runningUAT cases.BusinessanalystscanprepareUATcasesbysimplifyingthetestcasesgeneratedbyQAteams.

Normally user training should be provided after UAT if the new product isreplacing an existing one. Users will be able to test the product in a moreindependent andunbiasedway.But, if the product is a newone, user trainingshouldbeconductedbeforeUAT.Otherwiseuserswillhavedifficultiesinusingtheproduct,whichiscompletelynewtothem,andthiswillresultinlowertestcoverageratiosandlongerUATdurations.

Page 91: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

10.ProjectManagement

Page 92: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Whileprojectmanagersareresponsibleforprojectscopemanagement,businessanalystsareresponsibleforproductscopemanagement.

Product scope represents the featuresof theproduct tomeetbusinessanduserrequirements, whereas project scope is defined as the work that needs to beaccomplished to build and release the product with these specified features.Therefore, in order to define the project scope correctly, the project managershould assist business analysts in defining a clear and correct product scopealignedwithbusinessanduserrequirements.Otherwiseresourcesarerootedinthewrongdirection,andthisresultsinproject-levelwaste.

OutputTrap

In addition to scope management, time and cost management are the othercriticalknowledgeareasinprojectmanagement.Sometimesthepressuretomeettimeandbudgettargetscanleadprojectmanagerstofocusmoreongeneratingoutputs (deliverables) than on outcomes (value).However, if the requirementscannotbemet, theprojectwon’tbe successful even if it is completedon timeand within budget constraints. To prevent this “output” trap and assure thedeliveryofvalue-adding“outcomes,”projectmanagers should alwayswork incollaborationwithbusinessanalyststoensurevaluecreationateverystepoftheproject. They should keep all project stakeholders connected throughout theproductdevelopmentlifecycle.

Toachievethis,projectmanagersshouldmanagetheprojectinthefield.Someproject managers spend most of their time at the PMO (project managementoffice) instead of attending requirements-gathering meetings, reviewingrequirementsdocuments,andparticipatingintestingsessions.

In the lean approach, projectmanagers shouldgo to thegembaandhavehighbandwidth communicationwith project stakeholders and customers throughouttheproductdevelopmentlifecycle.

WholeOptimizationInsteadofSuboptimization

The lean approach aims to remove the checks and balances within project

Page 93: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

stakeholderstoensurecollaboration.

Although segregation of duties is important to manage accountability amongteammembers,itshouldnotresultinsilos.

Silosusuallyformduetomicromanagementofseparateteamssuchasbusinessanalysts, designers, developers, and quality assurance specialists.Micromanagementresultsinthesuboptimizationofeachgroup’sobjectiveswithoutput-oriented KPIs (key performance indicators), such as the number ofrequirements documented, number of defects found, or number of codes built.Butintheleanapproach,KPIsaimtooptimizetheobjectivesofthewholeteam.For instance, KPIs such as “the number of user requirements satisfied at aspecificrelease”or“percentofbusinessrequirementtargetsmetatfirstrelease”will help the projectmanager keep every project stakeholdermotivated in thesamedirectiontogeneratedesiredvalueforcustomers.

In applying the lean approach for the first time, project managers shouldrememberthat“itisnotthestrengthofwavesthatshapestherocks,butitistheirpersistence.”Thus,insteadofgivingupearly,theyshouldcontinuouslymotivatetheirteamstoapplyleanprinciplesandtechniquestotheirprojectsbymanaginganykindofinternalresistance.

EndoftheStoryattheCECCompany

Thanks to applying the lean approach to the CEC mobile applicationdevelopmentproject, theproject teammanaged tobevalueoriented, customercentered, and iterative throughout the project. This helped the CEC companysatisfyallofthebelowprojectobjectives:

-Differentiate itselfbyhavingamobilechannelearlier thanallotherconsumerelectronicscompanies

-BeinnovativeincreatingamobilesaleschannelwithfeaturesthatweredirectlydrivenbyCECcustomerneeds

-Preventwastebyonlyinvestinginfeaturesthatwerereallynecessary

-Improvescalethatwasoncelimitedtothenumberandvisibilityofdealers

-Satisfy themarketing business unit by releasing themobile application at thetimetheyrequested

Page 94: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

-Beawareofrisksearlyandmitigatethemquickly

The project was completed on time to the high satisfaction of all projectstakeholders. For this project, upper management realized the benefits of theleanapproachanddecidedtoapplythisapproachtoallotherprojects.

Page 95: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups

Index

Page 96: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 97: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 98: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups
Page 99: Business Analysis Methodology Book: Business Analyst's Guide to Requirements Analysis, Lean UX Design and Project Management at Lean Enterprises and Lean Startups