1 / 19

The Agile Classroom

Session 2: Agile Planning: Requirements to Complete a Product Backlog. The Agile Classroom. March 17, 2010. Moderators: Duncan Kinchen, Red Fox Consulting, LLC Sandi Kappus, Air Wisconsin, Inc.

randi
Télécharger la présentation

The Agile Classroom

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Session 2: Agile Planning: Requirements to Complete a Product Backlog The Agile Classroom March 17, 2010

  2. Moderators:Duncan Kinchen, Red Fox Consulting, LLCSandi Kappus, Air Wisconsin, Inc. Duncan Kinchen is a Senior Project Manager and a Certified Scrum Master (CSM) with over 26 years of experience. Based in Green Bay, Duncan has led projects of all sizes in a broad range of industries. Starting with Rapid Application Development in Europe before graduating into Scrum, Duncan has followed the increasing implementation of Agile methodologies for years and is committed to the advancement of Agile principles wherever possible. He is currently one of the Program Directors for the Northeast Wisconsin (NEW) Agile Users Group. Sandi Kappus is an Applications Manager and a Certified Scrum Master (CSM) with Air Wisconsin Airlines the largest independently held regional airline in the United States, Air Wisconsin Airlines Corporation (AWAC) performs flying services for US Airways, and ground handling services primarily for United. Sandi has over 10 years of experience in business analysis, project management and portfolio management spanning the financial sector as well at the airline industry.  Sandi currently sits on the board for the NorthEast Wisconsin Chapter of the International Institute of Business Analysis (IIBA).  Sandi has actively been practicing the agile methodology as a business analyst, product owner and scum master and is committed to the development of business analysis and Agile methodologies.

  3. Agile Methodologies- The Development Landscape -

  4. Agile Requirements and the Product Backlog

  5. Requirements Gathering – High Level • Being true to the Agile Methodology you will need to account for: • Technical changes • Changing business needs • Process improvement • Enhancing the value of the application

  6. Traditional Requirements Gathering Process

  7. Agile Requirement Process

  8. Example: Requirements Board Postit Collections and User Stories

  9. How detailed should Agile Requirements be? Detailed enough for the team to start work from. Further details can be established and clarified during development.

  10. INVESTin Good Requirements Independent– Agile Requirements should be as independent as possible. Negotiable– Agile Requirements are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development. Valuable – Agile Requirements should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks. Estimatable– Agile Requirements need to be estimated. They need to provide enough information to estimate, without being too detailed. Small – Agile Requirements should be small. Not too small. But not too big. Testable – Agile Requirements need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.

  11. Key Principles for Agile Requirements Active user involvement is imperative Agile teams must be empowered to make decisions Requirements emerge and evolve as software is developed Product Owner involvement is key to success Enough’s enough – apply the 80/20 rule Cooperation, collaboration and communication

  12. Increasing Detail through Interaction over Time

  13. Sometimes Rarely 16% 19% Never Often 45% 13% Always 7% Often or always used: 20% Rarely or never used: 64% Getting Priorities Right… Features and functions used in a typical system Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

  14. The Product Backlog

  15. Agile Requirement Process

  16. Agile Requirements Summary Agile Requirements combine written and verbal communications, supported with a picture where possible. Agile Requirements should describe features that are of value to the user, written in a user’s language. Agile Requirements detail just enough information. Details are deferred and captured through collaboration - just in time for development. Test cases should be written before development, when the User Story is written. Agile Requirements should be Independent, Negotiable, Valuable, Estimatable, Small and Testable.

  17. Writing Good User Stories- Links http://www.agile-software-development.com/2008/04/writing-good-user-stories.html (Kelly Waters) http://www.agilemodeling.com/artifacts/userStory.htm (Scott Ambler) http://www.extremeprogramming.org/rules/userstories.html http://www.userstories.com/ http://www.codesqueeze.com/the-easy-way-to-writing-good-user-stories/ http://www.mountaingoatsoftware.com/books/2-user-stories-applied-for-agile-software-development (Mike Cohn)

  18. Writing Good User Stories- Literature User Stories Applied: For Agile Software Development by Mike Cohn Agile Requirements & User Stories: Extreme Programming Practices for Project Managers and Business Analysts by Louis Molnar

  19. Next Session: Sprint PlanningAgile Planning – Estimating and Prioritizing Requirements (Delivering Value from the Product Backlog)

More Related