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

5,733 views
5,550 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.

0 Comments
13 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,733
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
151
Comments
0
Likes
13
Embeds 0
No embeds

No notes for slide
  • 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.Learning Objectives* Learn how techniques such as Impact Mapping can help you narrow your focus and test your assumptions* Learn how to use analysis models to identify, and further explain user stories* Learn how to establish a definition of ready for your effort and use it to determine "just enough" business analysis
  • Do we have a complete solution?Are we building things we shouldn’t?
  • Understand the problem to solve (state it as a goal)Discover possible solutions (options) –impact mappingIdentify the best solution (make assumptions about which has the biggest impact)Transfer the knowledge of that solution to the whole team (Models and stories) Why are you doing the effort? What problem are you trying to solve? Is the problem worth solving? - Make it measurable. This is the value you are seeking to deliver.What are the different things that you can do to realize that value. Impact Mapping is one technique that can get you that information. Creating the map generates options.Which of those options seems the best to help you realize the value – prioritizing the items on the impact map.Use analysis models to describe the option, user stories to identify the changes needed to enact the option, and the models again to further describe the stories.***********We first describe the problem we are trying to solve in terms of some measurable goal. Looking at this goal and comparing it against our decision filters from strategy tells us if the problem is worth solving.We then use Impact Mapping to identify possible solutions. (Grow the Map) and then prioritize the map to identify good solutions. Of course we implement those solutions to determine if they are viable and will result in the impact we want, and to verify assumptions we are making.
  • Add some animation hereTo talk about how do you get there.
  • Why are we doing this?
  • Who can produce the desired effect and who can obstruct it?
  • How should our actors behavior change?
  • Photo from: http://janbierens.com/2012/12/03/when-you-are-gone-your-blog/Photo credit: http://janbierens.com/wp-content/uploads/2012/12/and_now_its_time_for_something_completely_different.jpg
  • Ask audience for possible storiesAsk audience for suggestions of splitting into smaller stories.
  • Even though I teach people to do this, I sometimes need a reminder… And it can come from anyone on the team.
  • Green – in estimate deliveredBlue – not in estimate, delivered
  • Remember to ask the people consuming the information what they need in order to move forward.
  • CoreKanban PrinciplesVisualize workflowLimit WIPMeasure & Manage FlowMake process policies explicitIdentify & implement improvement opportunities through Lean and related principles and practicesEmergent PropertiesManage QuantitativelyPrioritize by (opportunity) cost of delayOptimize value with classes of serviceManage risk with allocation of capacityEncourage process innovation
  • 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

    ×