Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Analysis In Agile: It's More than Just User Stories

7,485 views

Published on

A common question asked by teams adopting agile is "what does business analysis look like in agile?" The common answer is "writing user stories".  

WRONG!  

Okay, maybe not wrong, but certainly not the whole story (pardon the pun).  Business analysis in agile is concerned with understanding the problem and possible solutions in order to ensure the team is building the right thing. User stories can be helpful, but are certainly not sufficient for doing that.

In this session, Kent McDonald describes how you can perform just enough business analysis  to discover the right things to build. This includes how to really use value to decide what to build first, why process flows, data models, and mockups are still extremely helpful, and why the function of user stories is more important than their form.

Along the way, Kent shares examples from a system replacement project he is working on and suggests ways you can apply these techniques to your own projects.

  • Be the first to comment

Analysis In Agile: It's More than Just User Stories

  1. 1. Analysis in Agile:It’s More Than Just User StoriesKent J. McDonald@beyondreqs
  2. 2. What does business analysis look likein Agile?
  3. 3. Agile approaches describe deliveryWhere does this come from?
  4. 4. And then amiracle occurs
  5. 5. Voila! A Backlog.But there may besome problems…
  6. 6. Do you have a completesolution?
  7. 7. Is the backlog morelike a wish list?
  8. 8. Use models andstories to describewhat to buildHow to determine what is“just enough”Analysis in AgileUse value to determinethe right thing to build
  9. 9. VALUEINPUTSINPUTSPROCESSUse value todetermine the rightthings to buildOUTPUTSVALUE
  10. 10. An example would behandy right about now
  11. 11. Enterprise System ReplacementNewSystem
  12. 12. Initial Approach to AnalysisNewSystem
  13. 13. New Approach to AnalysisNewSystem
  14. 14. Impact Mapping© Gojko Adzic 2012For more information:impactmapping.org
  15. 15. Goals
  16. 16. Why are we doing this?© Gojko Adzic 2012
  17. 17. Actors
  18. 18. Who can produce the desired effectand who can obstruct it?© Gojko Adzic 2012
  19. 19. Impacts
  20. 20. How should our actors behaviorchange?© Gojko Adzic 2012
  21. 21. Deliverables
  22. 22. What can we do asa delivery team tosupport therequired impacts?© Gojko Adzic 2012
  23. 23. © Gojko Adzic 2012
  24. 24. Validating assumptions© Gojko Adzic 2012
  25. 25. Identifying user stories© Gojko Adzic 2012IMPACT
  26. 26. Story Mapping
  27. 27. Identified our personas
  28. 28. Identified their key activities
  29. 29. Split the key activities into smallchunks
  30. 30. Organized stories into “minimumviable products” aka releases
  31. 31. CaveatsGood for organizing backlogDoesn’t explicitly consider valueUseful when desired functionality is knownNot too helpful for truediscovery
  32. 32. Use models and stories to describewhat to build
  33. 33. User stories are helpful, but notsufficientCardConversationConfirmationIndependentNegotiableValuableEstimableSmallTestableIn order to finalize theprogramAs Connie Conference ChairI need to schedule the acceptedsessions into rooms for theconference
  34. 34. Stories are Coupons for aConversation…By JB Rainsbergerhttp://www.jbrains.ca/permalink/user-stories-a-ticket-for-a-conversation
  35. 35. Use models to identify storiesIn order to providefeedback to submittersAs ReedI need to submit a reviewof a sessionAs ReedI can add a review to asessionSo that I can providefeedback to SamAs SamI can view reviews on mysessionSo that I can getfeedback on my sessionAs ReedI can edit my reviewSo that I can react tochanges Sam made to hissubmission
  36. 36. Stories representchanges that need tooccurIn order to guidesubmitter track selectionAs Peter Program ChairI want to organize tracksinto themes
  37. 37. WhatIaskedfor
  38. 38. The delivery team sets me straight
  39. 39. And comes up with a better solution
  40. 40. Use models to further describe storiesIn order to providefeedback to submittersAs ReedI need to submit a reviewof a session
  41. 41. These are our “stories”.These are trulyplaceholders
  42. 42. AcceptanceCriteria &Examples
  43. 43. Just Enough Analysis
  44. 44. Do only what you actually need to do
  45. 45. Definition of Ready
  46. 46. Team discusses and agrees
  47. 47. Possible things to includeInteractionDiagramsPrototypesWireframesSampleDataTestableexamplesAcceptanceCriteriaStateDiagramsSmall StoryUX TestApprovalsDependencyidentifiedStakeholdersidentifiedDefinition of Ready
  48. 48. Analyze when youneed to, not before
  49. 49. Discovery and DeliveryUnderstand theProblemLearn fromFeedbackDeep dive onmost valuablefeatureIdentifysolution(Features)Demo/DeployDevelop/TestStories withAcceptanceCriteria &ExamplesDiscovery Delivery
  50. 50. When do we do this stuff?CreateImpactmapSelect nextdeliverablefrom mapUpdateImpactmapIdentifystoriesFurtherdescribestories
  51. 51. Discovery and Iterative DeliveryDiscoveryDeliveryDeliver iteration 1stories Discovery foriteration 2 Support iteration1 deliveryDeliver iteration 2stories Discovery forIteration 3 Support iteration2 deliveryDeliver Iteration 3stories Discovery forIteration 4 Support iteration3 delivery Planning Identify stories Discovery forIteration 1•Developmentenvironmentsetup•“spikes”Iteration 0 Iteration 1 Iteration 2 Iteration 3supportdevCustomer input in Agile Projects by Lynne Miller
  52. 52. Discovery & Delivery in Flow
  53. 53. Best of Both WorldsDiscovery BoardDelivery Board
  54. 54. Discovery BoardDefn ofReadyStoryStoryStoryStoryStoryStoryStoryStoryStory StoryStoryStoryStoryStoryFeatureFeatureFeatureFeatureDefn ofEstimatableInclude: Story Acceptance CriteriaStoryStoryInclude: Story Acceptance Criteria SizeInclude: Story Acceptance Criteria Size Mockup Dependencies Stakeholder list Examples
  55. 55. If you remember nothing else… Use value to determinethe right thing to build User stories areplaceholders. Nothingmore Use models and examplesto describe the solution Collaborate to figure outwhat is “just enough”
  56. 56. Questions?Kent McDonaldkentjmcdonald@gmail.com@BeyondReqswww.beyondrequirements.comSlides available from:http://www.slideshare.net/kentjmcdonald

×