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.

Agile Business Analysis - The Key to Effective Requirements on Agile Projects

Apresentação de Shane Hastie no BA Brazil 2011 (Porto Alegre, RS)

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

Agile Business Analysis - The Key to Effective Requirements on Agile Projects

  1. 1. 22/11/2011 Agile Business Analysis The Key to Effective Requirements on Agile Projects Shane Hastie MIM, CSM Debunking the Myths In Agile projects we don‟t just sit down and write code like free- form poetry! – James King(c) Software Education, 2010 1
  2. 2. 22/11/2011 Directions • Why Agile? • Agile Needs Analysis • Agile Changes Analysis • The Agile Analyst • Different Engagement Types • Agile Analysis Tools • What Next? • Q&A 64% 20% 16%(c) Software Education, 2010 2
  3. 3. 22/11/2011 Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Manifesto para Desenvolvimento Ágil de Software Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.(c) Software Education, 2010 3
  4. 4. 22/11/2011 The Agile Lifecycle Envision Speculate Close 5% 10% Explore 80% 5% Uncertainty in the Project Goal What our SRS spec’d Uncertainty in Stakeholder Courtesy Philippe Kruchten Satisfaction Space Source: W. Royce, IBM The Right Initial State Actual Path and Solution precision of artifacts(c) Software Education, 2010 4
  5. 5. 22/11/2011 Inside an Iteration Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10 Iteration Task Task Task Task Task Task Task Task Wrapup Planning Work Work Work Work Work Work Work Work Daily Daily Daily Daily Daily Daily Daily Daily Daily Standup Standup Standup Standup Standup Standup Standup Standup Standup Task Task Task Task Task Task Task Task Present/ Work Work Work Work Work Work Work Work Retrospect Backlog Iteration Backlog As a xxx I want yyy so that zzz Story 1 Story 1 Iteration Story 2 Story 2 Planning Story 3 Story 3 Story 4 Iteration Tasks Story 5 Task 1 Story 6 Task 2 Story 7 Task 3 Story 8 Task 4 Story 9 Task 5 Task 6 Epic 1 Task 7 Task 8 Epic 2 Task 9 Uncompleted Story 3 Task 10 Epic 3 Agile Needs Analysis The hardest part of building any software system is determining precisely what to build Frederick Brooks(c) Software Education, 2010 5
  6. 6. 22/11/2011 But the Perception Worse It should be red or I want a I like green. range of color purple. options including green, blue , and purple It shall be green.(c) Software Education, 2010 6
  7. 7. 22/11/2011 Agile Changes Analysis Business Analysis Planning and Monitoring Enterprise Analysis Solution Requirements Elicitation Assessment & Analysis Validation Requirements Management and Communication Current release: V2.0 (© 2009) The Shocking Truth About Requirements(c) Software Education, 2010 7
  8. 8. 22/11/2011 They Change! Are Requirements Obsolete?(c) Software Education, 2010 8
  9. 9. 22/11/2011 Reducing Waste Leave things until the last RESPONSIBLE moment Photo by Nick Wheeler Progressive Elaboration Vision Personas & Goals Epics Stories Acceptance Criteria(c) Software Education, 2010 9
  10. 10. 22/11/2011 Example: Vision Box(c) Software Education, 2010 10
  11. 11. 22/11/2011 Example: User Profiles(c) Software Education, 2010 11
  12. 12. 22/11/2011 Epics • Elementary Business Process • One person, one place, one time • Could come from a process map • Someone doing something • Enough to prioritise • Fulfil to the Vision & Goals(c) Software Education, 2010 12
  13. 13. 22/11/2011 User Stories • User Stories • Guidelines for success • Just-in-time • Three C‟s – Card – Conversation – Confirmation Common format: “As a <role> I want <thing to be delivered> so that <reason for the need>” From Epic to Stories • Identify the key process elements • Each piece of CRUD • Consider the UI components • “Happy days” steps • “When things go wrong” – preventing bad things from happening(c) Software Education, 2010 13
  14. 14. 22/11/2011 How Do Your Stories Smell? • The Value of Quality • Performance • Efficiency • Reliability • Functionality • Useability • Maintainability(c) Software Education, 2010 14
  15. 15. 22/11/2011 Acceptance Criteria • 3rd C – Confirmation of the story • Just-in-time • Progressively evolve during backlog grooming and development • Add details as needed • Process flows • Data structures • UI mockups • Technical notes • Examples • Whatever is needed . . . • BDD Format • <given> <when> <then> • Test design criteria Behaviour Driven Development • Express needs as behaviour using scenarios • Scenario: Upgrade with sufficient air miles available Given a traveller has a valid reservation in economy class and he has sufficient air miles available and there is a seat available in business class when he requests an upgrade then the upgrade should be provided and his air miles balance reduced and the economy seat released and the business class seat reserved(c) Software Education, 2010 15
  16. 16. 22/11/2011(c) Software Education, 2010 16
  17. 17. 22/11/2011 The Agile Analyst Scrum Roles Scrum Master Product Owner  The Delivery Team(c) Software Education, 2010 17
  18. 18. 22/11/2011 Product Owner • Greater project engagement and leadership • Understands the business & project vision • Empowered decision maker • Daily involvement • Review the plan every iteration • How competent and committed? Where is the BA? Product Owner? Scrum Master? A Team Member?(c) Software Education, 2010 18
  19. 19. 22/11/2011 Changing the Rules Break down the walls Need to be a facilitator Open the communication channels Keeper of the value context Different Engagement Types 1. Traditional Requirements Gatherer 2. Surrogate Product Owner 3. Second in command (2IC) 4. Business Coach 5. Co-ordinator 6. Facilitator 7. Not required / Unemployed?(c) Software Education, 2010 19
  20. 20. 22/11/2011 Agile Analysis Guidelines • See The Whole • Think as a Customer • Analyse to Determine What is Valuable • Get Real Using Examples • Understand What is Doable • Stimulate Collaboration & Continuous Improvement • Avoid Waste(c) Software Education, 2010 20
  21. 21. 22/11/2011 Other Types . Quality .. Requirement Model Constrained by (NFR) Elaborated by Optionally State Architecture Diagram Requirement Class Backlog Item Diagram Realised by Use Case Epic Story UML Model courtesy of Dean Leffingwell Process Model – Who? What? When? 44(c) Software Education, 2010 21
  22. 22. 22/11/2011 Entity Relationship Diagram – With What? Decision Table – What? How? Condition Statements Rules Purchased Full Fare Ticket? Y Y Y Y N N N N Received Upgrade in Last 6 Months? Y Y N N Y Y N N Gold Status? Y N Y N Y N Y N Action Options Action Entries Free Upgrade X X X Discounted Upgrade Offer X X No Upgrade X X X(c) Software Education, 2010 22
  23. 23. 22/11/2011 Decision Tree – What? How? Ticket Type? Freq Flyer Last Upgrade? Level? ACTIONS <= 6 Months No Upgrade Not Gold >6 Offer Discounted Full Months Upgrade Offer Fare Gold Upgrade? Free Upgrade <= 6 Months Offer Discounted Discounted Upgrade Gold >6 Free Upgrade Months Not No Upgrade Gold State Transition Diagram – What? How?(c) Software Education, 2010 23
  24. 24. 22/11/2011 Use Cases – What? How? USE CASE # 002 Amend Reservation Goal in Context This use case allows a reservations operator to amend or cancel a reservation in response to a caller request Scope and Level Flight Reservations System Primary Task Preconditions The reservations system will be up and running, the Reservations Operator will have logged into the system Success End Reservation details amended or removed Condition Failed End No change to reservation details Condition Primary, Reservations Officer (RO) Secondary Actors Caller Trigger This use case begins when the RO receives a request to change an existing reservation DESCRIPTION Step Action 1 The RO selects the reservation to amend (search criteria/mechanism TBD, possibly by reservation number, caller name, passenger name, journey details . . .) 2 The system displays the reservation and journey details for all journeys not yet started 3 … Are User Stories Simply Degenerate Use Cases? Upgrade Seat(c) Software Education, 2010 24
  25. 25. 22/11/2011 Use Cases Versus User Stories Use Case User Story Transactional Statement of Value Scope is “user valued Scope is determined by what transaction” can be implemented in one iteration Conceptual (Model) Descriptive Requirement Requirements place holder Know Your Context Source: Philippe Kruchten Octopus Model(c) Software Education, 2010 25
  26. 26. 22/11/2011 Agile Extension to the BABOK™ • Available for Download • We NEED Your Feedback • _Development/Agile_Extension.aspx BABOK™ V3.0 • Change Framework • Multiple Perspectives – „Motivation‟ – Portfolio – Program/Project – Specialisations(c) Software Education, 2010 26
  27. 27. 22/11/2011 Any questions? Contact me: • Email • Web • Blog • InfoQ articles • Twitter @shanehastie • Slides available from Options for Open Space • Enterprise Analysis • BABOK 3.0 Change Framework • Writing Good User Stories(c) Software Education, 2010 27