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

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 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 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

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

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

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

Building Our Release Backlog 8

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

Use Case Diagram – User Perspective Scott Ambler www.AgileModeling.com 10

Sample Process Diagram - Process Perspective Scott Ambler www.AgileModeling.com 11

UI Flow – Screen/UI Perspective Scott Ambler www.AgileModeling.com 12

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

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

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

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

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

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

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

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

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

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

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

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

Sample Team Definition of Done (Long!) 25

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

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

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

Test Examples

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

Sample UI Prototypes Scott Ambler www.AgileModeling.com 33

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

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

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

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!

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.

http://agiletraining.com	608
http://agiletransformation.com	159
http://mycourse.solent.ac.uk	96
http://translate.googleusercontent.com	2

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

by Sally Elatta on Jun 17, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 865

Statistics

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