Agile requirementspraguefinal


Published on

Published in: Education, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile requirementspraguefinal

  1. 1. Agile Requirements and Context Counts Cherifa Mansoura Webcast Agile community in Prague© 2009 IBM Corporation
  2. 2. Goals To understand what do we do differently in agile? To show that requirements still matter in agile To understand agile requirements practices To show that context counts, and one “process size” does not fit all To explore how to scale agile requirements practicesAgile Requirements at Scale 2
  3. 3. 3 Agenda 1 Agility and requirements 2 Achieving better requirements on agile projects: User stories and beyond 3 Brief introduction to Agile requirements at scale 4 Conclusion Agile Requirements at Scale 3
  4. 4. Agile Requirements: Strategies are changing Continual customer involvement Product owner represents the stakeholders Shared vision Understand business needs Focus on stakeholders goals Requirements elicitations Conversations, agile modeling, workshops Requirements analysis Performed “just in time” Requirements documentation User stories, storyboards, acceptance tests, agile models Test your documentation effectiveness : ”CRUFT” Measure Formality Improvised, more relaxed approachAgile Requirements at Scale 4
  5. 5. Traditional requirements practices are changing Specify acceptance tests while you gather requirements Iterative requirements planning & management adjusted with planning levels to take into account the progressive requirements specification Strategy Product Release Portfolio Iteration Product Day Release Most agile teams are concerned only with Iteration the three innermost levels of the planning Source: Scrum onion DayAgile Requirements at Scale 5
  6. 6. Agile brook down the barriers Prioritized Requirements Requirement List Agile planning 101 Requirements Master story Ve List loc specs it y Add user DoneCode Tests Create profile Done Tests Book Code reservation Done Make payment + MORE Silos Agile Team Collaborates One whole team with CustomerAgile Requirements at Scale 6
  7. 7. 7 Agenda 1 Agility and requirements 2 Achieving better requirements on agile projects: User stories and beyond 3 Brief introduction to Agile requirements at scale 4 Conclusion Agile Requirements at Scale 7
  8. 8. Agile Requirements Practices : How much is enough?Agile Requirements at Scale 8
  9. 9. Agile Requirements: User Stories User story is a concise, written description of a piece of functionality that will be valuable to a software stakeholder As a <role>, I can <goal> so that <business value> Epic User Stories are very large user stories Break epic stories into iteration-stories Product Backlog contains ranked list of user stories for a release User Stories are created at the beginning of the release Product Owner ranks list based on highest need to stakeholders But with input from team, e.g. high risk items rank highAgile Requirements at Scale 9
  10. 10. User stories: Ron Jeffrey’s 3 Cs Card As a (user role), I want to (goal) so I can (reason) What is the goal of a Example: user As a registered student, I want to view course details so I can create my schedule Conversation Discuss the card with a stakeholder. Just in time analysis (JIT) How to achieve the through conversations. goal using the Example: system? What information is needed to search for a course? What information is displayed? Confirmation Record what you learn in an acceptance test. How to verify if the Example: story is done and Student can access course catalog 24 x 7 hours complete, and the goal is achieved Student cannot choose more than three coursesA user story has 3 parts. If it doesnt, its not a user story.Agile Requirements at Scale 10 10
  11. 11. Acceptance tests Acceptance tests are high level tests and captured as confirmation They test the completeness of a user story or stories played during any sprint/iteration. They verify that the user’s goal is achieved using the system Write acceptance tests before coding Non-functional requirements and business rules are often captured as part of acceptance tests Are these acceptance Engage customer to define acceptance tests tests? As a registered student • Student can access course I want to access catalog 24*7 hours course catalog • Student cannot choose more content so I create than three courses my scheduleAgile Requirements at Scale 11
  12. 12. Acceptance Tests ExamplesAgile Requirements at Scale 12
  13. 13. Why use User Stories? Right size for planning, works for iterative development Defer detail until you have the best understanding you are going to have about what you really need Focus on user goals and business values Emphasize verbal rather than written communication Comprehensible by both Stakeholders and the dev team Stories support evolutionary developmentAgile Requirements at Scale 13
  14. 14. Definition of Done Every story needs to meet this definition to be counted Start with a manageable definition of Done Review definition of Done each iteration, try to add to it Done No Sev 1, Sev 2, Minimal Sev 3, Sev 4 Code reviews completed 80% Unit test coverage Test automation completed Documentation complete and reviewedAgile Requirements at Scale 14
  15. 15. Putting everything together: Iteration Planning Ve locity ~ 20 Product Backlog Size 60 As a customer I want to be 5 50 As a customer I want to be 3 40 As a administrator I want 2 Velocity of ~20, Rank Order St ory Point s Target ed 30 St ory Point s Co mplet ed 20 Select top 5 As a business planner I 3 10 stories (21 pts) As a customer I want to be 8 0 It erat io n 1 It erat ion 2 It erat io n 3 It erat ion 4 It erat ion 5 As a administrator I want 2 As a product owner I want 5 As a customer I want to be 1 As a customer I want to be 8 Iteration Planning 1. Pull stories from the top of your ranked list 2. Use the team velocity to determine how many stories to include in iteration Velocity = total story points completed on average over last ~ 3 iterations 3. Define Acceptance tests 4. Define the tasks required to complete the workAgile Requirements at Scale 15
  16. 16. 16 Agenda 1 Agility and requirements 2 Achieving better Requirements on agile projects: User stories and beyond 3 Brief introduction to Agile requirements at scale 4 Conclusion Agile Requirements at Scale 16
  17. 17. Agile scaling factors Team size Compliance requirement Under 10 1000’s of Critical, developers developers Low risk Audited Geographical distribution Domain Complexity Straight Intricate/ Co-located Global -forward Emerging Disciplined Enterprise discipline Agile Organization distribution Project Enterprise Delivery (outsourcing, partnerships) focus focus Collaborative Contractual Organizational complexity Technical complexity Flexible Rigid Heterogeneous, Homogenous LegacyAgile Requirements at Scale 17
  18. 18. Things to consider when you are scaling? Features , Use Cases, or User Stories How much discipline? Automation is the rescue? Need additional level of planning? Documentation? Reviews? DriveAgile Requirements at Scale 18
  19. 19. Use Cases or User Stories? Use Context A use case is A user story is the specification of a set of actions a simple, clear, brief description performed by a system, expressing a user’s goal for which yields an observable result that using the system under is, typically, development of value for one or more actors or other to deliver business value stakeholders of the system. (Unified Modeling Language - UML 2.0) Both methods are focusing on users and values to the users. Each has its own strengths and weaknesses. How do we bring together the best of the both worlds for Agile Requirements at Scale?Agile Requirements at Scale 19
  20. 20. Scaling factors make Agile hard? CLM to the rescue Agile planning 101 Prioritized/ranked Master story List Requirements List Add user Create profile Book reservation Te am Make payment ve lo cit y Continual Stories Defects Improvement Collaboration Sprint Test Scripts Builds Visibility to the Lifecycle traceability whole teamAgile Requirements at Scale 20
  21. 21. Agile requirements and large teams Communication and coordination risk increases with large teams Initial requirements and architecture envisioning is critical Coordination of requirements between subteams is important Team organization, architecture, and requirements must reflect each other Re-enforce the usage of product backlog for scope management Use simple tools, apply some agile practices such as active participation of stakeholdersAgile Requirements at Scale 21
  22. 22. Agile requirements and regulatory compliance You may need to adopt other requirements strategies, such as use cases or formal System Requirements Specifications (SRSs) BUT... read the regulations, because they likely don’t specify how, nor when, to capture the requirements Traceability is often a secondary, but important, part of the regulation BUT read the regulations, because they likely don’t specify the level of detail required You will likely need to write more documentation, particularly business rules and requirements pertaining to sensitive data BUT read the regulations, because you only need to do this to the extent of the risk of the project You may need to hold reviews BUT read the regulations, because they seldom require formal reviewsAgile Requirements at Scale 22
  23. 23. Agile requirements and geographically distributeddevelopment Geographically distributed teams incur significant communication risk Need a more “disciplined” agile requirements approach One that can address risks Automation is a “must” for requirements traceability, version control and collaboration Requirements dashboards and reporting on certain important measures become necessary Large team considerations applyAgile Requirements at Scale 23
  24. 24. Agile requirements and domain complexity Business process sketching may help understand the complex domain environment Rich-text, Images, links Process Might want to consider light-weight use Sketches cases instead Will likely need to do more user interface (UI) prototyping Active participation of stakeholders Shared throughout the life cycle is crucial for you Glossaries to understand their changing needs Feedback and Important: Complex domains don’t imply Dialogue that you need detailed requirements speculations UI Sketches and Use Cases StoryboardsAgile Requirements at Scale 24
  25. 25. 25 Agenda 1 Agility and requirements 2 Achieving better Requirements on agile projects: User stories and beyond 3 Brief introduction to Agile requirements at scale 4 Conclusion Agile Requirements at Scale 25
  26. 26. Implications for Business Analysts (BA) The BA goal is to build a shared understanding, it isn’t to write detailed documentation Expand your horizons and become a generalizing specialist Learn how to perform acceptance TDD so that you can capture requirements as executable specifications Recognize that one process size does not fit all, that you will need to be flexible Your primary goals should be to: Facilitate communication between stakeholders and developers Put developers in direct contact with stakeholders wherever possible Help developers learn better communication skillsAgile Requirements at Scale 26
  27. 27. Implications for Organizations Don’t be fooled by the agile rhetoric You still need to invest in modeling You still need to invest in requirements management Don’t be fooled by the traditional rhetoric Detailed documentation adds risk to IT projects Individual teams find themselves in unique situations, so will have unique tailorings of your processAgile Requirements at Scale 27
  28. 28. 28 © Copyright IBM Corporation 2010. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. Agile Requirements at Scale 28