Real World Effective/Agile Requirements - IBM Innovate 2010 -sally elatta

  • 9,368 views
Uploaded on

This is the presentation I offered at the IBM 2010 conference around real world techniques and best practices for effective requirements gathering and release planning. Enjoy!

This is the presentation I offered at the IBM 2010 conference around real world techniques and best practices for effective requirements gathering and release planning. Enjoy!

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Thank you for putting together a detailed presentation. I am having trouble understanding how this is agile. Describing simple and natural actions on part of the user seems complicated. A common problem is, customer's needs undergo progressive elaboration. How do these techniques fare when it comes to a change percolating through the system? My guess is, not very well.
    Are you sure you want to
    Your message goes here
  • I am having trouble understanding how this is agile.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
9,368
On Slideshare
0
From Embeds
0
Number of Embeds
11

Actions

Shares
Downloads
0
Comments
2
Likes
26

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

Transcript

  • 1. Real World Agile Release Planning and Story Breakdown Techniques Sally Elatta President, AgileTransformation.com Sally@AgileTransformation.com RDM-1131A The premiere software and product delivery event. June 6–10 Orlando, Florida
  • 2. 2 Speaker  Sally Elatta  President AgileTransformation.com  Taught over 1000+ and helped coach over 20+ teams  Background: Java/.Net Software Architect  Certified Scrum Practitioner & ScrumMaster  Certified IBM, Sun, Microsoft Professional  Sally@AgileTransformation.com I am simply a transformer. Someone who is really passionate about transforming individuals, teams and organizations to doing what they do better. I value instilling soft skills and leadership qualities in the people I coach. I believe in Servant Leadership as the way to lead change and create a culture of empowered teams, as opposed to Command and Control. 1 2
  • 3. 3 Agenda Challenges With Requirements Requirements Visioning and Brainstorming Requirements Break Down Requirements Deep Dive Real World Release Planning Techniques Best Practices and Tips 3 3
  • 4. Group Workshop What are the top challenges we face with Requirements on a project? What are the most common issues that cause project challenges?  Discuss this with others next to you and prepare some answers to share with all of us. 4
  • 5. Common Challenges with Requirements  Limited access to stakeholders  Not thinking outside of the „current‟ box  Conflicting priorities  Too much focus on one type of  Customers don‟t know what they requirement want  Not separating the What from the  Customers change their mind How  Getting the RIGHT SMEs  Developers don‟t understand the  Missing requirements problem domain  Jumping into the details too early  No clear definition of „Done‟  Moving from Abstract to Concrete Copyright© 2010 Sally Elatta AgileTransformation.com 5 5
  • 6. Addressing the Challenges with Requirements Gathering  Must Improve: Designing a process for requirements gathering so that you gather:  The Right Level of Requirement.  At the Right Time.  From the Right SME.  Using the Right elicitation/modeling techniques. Defining „Acceptance Tests‟ as core requirements and input into development. Engagement level of Product Owners and SMEs. Early and continuous user acceptance testing. Engagement level of Product Owner. Copyright© 2010 Sally Elatta AgileTransformation.com 6
  • 7. The 4 Step to Agile Requirements Gathering Copyright© 2010 Sally Elatta AgileTransformation.com 7
  • 8. Building Our Release Backlog 8
  • 9. Visioning • Aims to identify: Techniques • Vision Statement • High level vision • Objectives and objectives. • Conditions of • Key measures for • Stakeholder Satisfaction success. Interviews • Roles/ Personas • High level scope • Facilitator Led • Use Case Diagrams • Target users and Visioning • High Level Process key goals. Workshop Diagrams • High level backlog • Role-Playing • High Level UI Flow • High Level • High Level Backlog Modeling (Themes and Features) • Team Breakout and Converge Goal Output Copyright© 2010 Sally Elatta AgileTransformation.com 9
  • 10. Use Case Diagram – User Perspective Scott Ambler www.AgileModeling.com 10
  • 11. Sample Process Diagram - Process Perspective Scott Ambler www.AgileModeling.com 11
  • 12. UI Flow – Screen/UI Perspective Scott Ambler www.AgileModeling.com 12
  • 13. Requirements Brainstorming Techniques • Epics, User • To brainstorm a large number of Stories user stories. • Story Writing • Goal is breadth, not Workshop depth. • Post-it Note Brainstorming • Teams Breakout Converge Output Goal Copyright© 2010 Sally Elatta AgileTransformation.com 13
  • 14. Story Writing Workshops  Involve as many team members as possible.  Goal is to brainstorm and write as many user stories as possible under the themes identified. Leave the prioritization and evaluation for later.  Prepare the room with post-it notes, flip charts and markers.  Need an effective facilitator to run these meetings to keep folks on track. 14
  • 15. Attributes of a User Story  A small piece of a requirement that is „valuable‟ to the product owner. U-INVEST Attributes: Understandable Story Format: Independent “As a <role>, I want to <goal>” Negotiable “Ability to <goal>” Valuable Estimatable Small Testable 15
  • 16. Sample Stories As an Agent I As an Agent I want to view the want to add new ‘Current Leads’ lead information. report. As a BA I want to define the existing product return process. As the XYZ system As the EDW I want to receive System, I want to new member have ABC file enrollments each loaded on a night. schedule. 16
  • 17. Requirements Breakdown • To breakdown Techniques • User Stories existing list of epics into small user stories. • Facilitator Led Workshop • All Stories should follow • Post-it Note U-INVEST. • Teams Breakout Converge Output Goal Copyright© 2010 Sally Elatta AgileTransformation.com 17
  • 18. Breaking Down the EPICS  Epics are large stories that need to broken down so they can be development-ready. They could be either Compound or Complex.  Compound means they have other independent stories within them.  Complex means that it is really one big independent story, but to get it done, we need to break it down to reduce it‟s complexity.  You break down epics during: Initial story brainstorming. During story sizing. During sprint execution when realizing scope is larger than anticipated. 18
  • 19. Real World Methods for Story Break Down  We wanted to share some real world methods we‟ve used with various teams to break down Stories. Process Based Breakdown CRUD – Function Base Breakdown Business Rule Based Breakdown User/Platform Based Breakdown Copyright© 2010 Sally Elatta AgileTransformation.com 19
  • 20. Process Based Breakdown  Walk through the process steps it would take to get that Story completed. When done, investigate each step and ask yourself if this step could be an independent valuable testable story of it‟s own?  „As a student I want to register for a course‟ Browse View Register Login available course for courses details course Copyright© 2010 Sally Elatta AgileTransformation.com 20
  • 21. CRUD – Function Based Breakdown  Apply CRUD (create, read/search, update, delete)  Trigger words: Manage, Administer, Control, Setup, Configure  Example: „As a mobile user I want to manage my greetings‟ As a mobile user I want to create a default greeting. As a mobile user I want to modify my default greeting. As a mobile user I want to delete a greeting. Copyright© 2010 Sally Elatta AgileTransformation.com 21
  • 22. Business Rule Breakdown  Break down the business rules into simple/complex, positive/negative rules.  Start with the „simplest‟ story, then add complexity as you go.  Example: As a loan officer, I want to process a loan application: Process a simple loan application that is approved. Process a simple loan application that fails. Process a complex loan application that is approved. Process a complex loan application that fails. Copyright© 2010 Sally Elatta AgileTransformation.com 22
  • 23. User or Platform Based Breakdown  You can break down Stories based on the different user types (customer, agent, administrator) or different platforms it will be accessed via (mobile, portal, desktop) as long as additional work is needed to implement these.  Example: “As a phone user I want to listen to my voice mail”  As a mobile user I want to listen to my voice mail  As a portal web user I want to listen to my voice mail  As a desktop phone user I want to listen to my voice mail Copyright© 2010 Sally Elatta AgileTransformation.com 23
  • 24. Building a Release Plan  There are multiple steps to creating a release plan. Here is generally the most common activities: Build the backlog. Prioritize and size each story. Define what „Done‟ means for your team. Determine your iteration length. Estimate initial velocity. Map stories to iterations based on this estimate. Add fall-through, hardening, and pre-release iterations where needed. Arrive at initial delivery date estimate (for scope driven efforts) or Arrive at rough scope that could delivered by a specific date (for date driven projects). Copyright© 2010 Sally Elatta AgileTransformation.com
  • 25. Sample Team Definition of Done (Long!) 25
  • 26. Planning for Additional Iterations  Fall-through iterations are needed after every 4 or 5 development ones. They are planned to be very light so they can be used to help complete any work that „fell through‟ from one iteration to the other.  Hardening or Quality iterations are added to do cross-team integration testing, regression testing, resolve any technical debt issues, do early alpha/beta testing ..etc.  A Pre-Release iteration is added before moving to production to prepare for this release for deployment. It includes user training, help doc finalization, acceptance and transition to support teams. Copyright© 2010 Sally Elatta AgileTransformation.com
  • 27. Sample Release Plan As a Group, Let‟s Review the “Sample Agile Release Plan” Copyright© 2010 Sally Elatta AgileTransformation.com 27
  • 28. Release Burn Up Chart Copyright© 2010 Sally Elatta AgileTransformation.com
  • 29. Story Deep-Dive (Details of a Story) • Identify detailed Techniques level requirements • Acceptance for each story. Tests • This should be • Facilitator Led • Business done a few weeks Workshop Rules before this Story • Teams • Test Examples will be Breakout • UI Prototype implemented. Converge • Activity Diagram Goal Output Copyright© 2010 Sally Elatta AgileTransformation.com 29
  • 30. Sample Acceptance Test Cases “A customer can pay for shopping cart items using a credit card” Test with VISA, MasterCard and American Express (pass) Test with Diner‟s Club (fail) Test with bad and missing 3 digit codes (fail) Test with expired cards (fail) Test with a purchase amount over the card limit (fail) 30
  • 31. Test Examples
  • 32. Business Rules  In some cases, the test itself contains the business rule itself. In other cases you will need to provide the list of business rules that apply to that test case.  1.1-TC1 „Verify that student eligibility rules are applied correctly during registration‟ TC1-BR1: Students with a „hold‟ record cannot register on the site. TC1-BR2: Students with outstanding payment from last semester cannot register. TC1-BR3: Student already registered cannot register again. 32
  • 33. Sample UI Prototypes Scott Ambler www.AgileModeling.com 33
  • 34. Managing Change  Rule #0: Identify Breadth then Break Stories Down! The more you focus on doing this right at the beginning the less “new scope” you‟ll have.  Rule #1: Assess the Impact When new requirements or changes are made, allow the team to assess and report the impact to the schedule. Don‟t just accept blindly.  Rule #2: Provide Options Let the Product Owner know they have options. Based on the impact, they are welcome to add but may need to also remove from the bottom of the list.  Rule #3: Product Owner Controls Scope Product Owner must control scope, not the Project Manager. They must be empowered to make decisions and clearly know schedule impacts and options. Copyright© 2010 Sally Elatta AgileTransformation.com 34
  • 35. Managing Change ..  Rule #4: Track the Changes! Don‟t just add and change requirements without tracking!  Rule #5: Deep-Dive Just in Time to Reduce Impact of Change Don‟t invest too much upfront on each requirement. Decide as late as possible, deliver as fast as possible!  Rule #6: Provide Stability Establish concrete rules for introducing new requirements. The team needs to focus during an iteration and should only address new scope in the following iteration. Copyright© 2010 Sally Elatta AgileTransformation.com 35
  • 36. Sample Change Management Tracking Copyright© 2010 Sally Elatta AgileTransformation.com 36
  • 37. 3 7 Summary  Addressing the challenges with requirements starts by designing a simple yet effective process.  We need to differentiate between the levels of requirements.  Using simple modeling and effective facilitation techniques can dramatically improve requirements gathering.  Release planning is a multi-step activity. For more Agile related training and coaching, please visit us: www.AgileTransformation.com www.AgileTraining.com 37
  • 38. 3 8
  • 39. 3 9 Daily iPod touch giveaway SPONSORED BY  Complete your session surveys online each day at a conference kiosk or on your Innovate 2010 Portal!  Each day that you complete all of that day‟s session surveys, your name will be entered to win the daily IPOD touch!  On Wednesday be sure to complete your full conference evaluation to receive your free conference t-shirt!
  • 40. 4 0 www.ibm/software/rational © 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.