Your SlideShare is downloading. ×
  • Like
Analysis In Agile: It's More than Just User Stories
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

  • 4,630 views
Published

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

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,630
On SlideShare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
111
Comments
0
Likes
7

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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

Transcript

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