Agile Requirements Definition and Management

2. Agile Requirements Definition and Management Overview: Will cover several ways to improve Agile Requirements Definitions and how to manage them in an iterative software development environment. Objectives: Through this presentation you will learn how to: Debunk the myth that in Agile software development, documentation is not required or useful. How to incorporate a Requirements Backlog iteration to feed the Product Backlog. And then see several ways to improve those Requirements.

3. Presenter Bio: Ken Ward Certified Scrum Professional. Ken has over 30 years experience in IT field. Ken has extensive development experience with team/project lead positions leading to Project Management.  His first Scrum project delivered ahead of time and under budget in 2001.  He’s been involved with several successful Scrum implementations at fortune 500 companies, and he has had experience with several high profile state government projects throughout his career. http://www.agile-foundation-training.com/

5. Scrum • In Simplicity

8. Agile Requirements • Preview Process Threads • Functional Requirements Documentation (FRD) • Interactive Requirements Documentation (IRD) • CONOPS (Concept of Operations) • IEEE standard exists stating "A ConOps is a user-oriented document that describes system characteristics for a proposed system from the users' viewpoint. The ConOps document is used to communicate the overall quantitative and qualitative system characteristics to the user, buyer, developer and other organizational elements (e.g. training, facilities, staffing and maintenance). It is used to describe the user organization(s), mission(s) and organizational objectives from an integrated systems point of view." • Other Required Documents

10. What practices can help requirements? • Acceptance criteria • ATDD • BDD

15. Using “Given-When-Then” to Discover and Validate Requirements In the book: Discover to Deliver: Agile Product Planning and Analysis they discuss the usefulness of the “Given-When-Then” technique to explore (discover) and confirm (validate) product options. Here we summarize the technique*, brainchild of Dan North. • Post by Mary Gorman and Ellen Gottesdiener of EBG Consulting

16. What it is • Given-When-Then (GWT) is a structured format for expressing scenarios with example data, including pre- and post-conditions. • Usefulness • GWT helps project stakeholders (business, customer and technology partners) communicate using business domain language. You can use GWT to explore product options and confirm selected options in a concrete, tangible way. Often called “specification by example,” GWT provides living documentation for your delivered product. It simultaneously specifies requirements while identifying acceptance tests, thereby streamlining discovery and delivery.

17. What You Need to Know • GWTpulls together the four functional dimensions of the 7 Product Dimensions: User, Action, Data, and Control (business rules). (For more on the 7 Product Dimensions, see our book Discover to Deliver, at the end of this Tip.) • Here’s how GWT works. For a specific story, scenario and business rule, you analyze 3 things, asking and answering these questions: • Given: What is the context of the system? What pre-condition must be true before the action is tested? What data is in the system? • When: What will be tested? What input data will be tested via the business rule when the action occurs? • Then: In response to the action, what is the observable outcome? What are the expected results? What is the post-condition (state) or output data observable by the user?

18. Links to sources • http://www.scrumalliance.com/articles/398-agile-requirements-definition-and-management • http://onespring.net/blog/agile-requirements-definition-and-management-rdm/ • http://www.methodsandtools.com/archive/atddreadysprintbacklog.php?goback=.gde_43421_member_158914683 • http://blogs.versionone.com/agile_management/2013/01/04/using-%E2%80%9Cgiven-when-then%E2%80%9D-to-discover-and-validate-requirements/?mkt_tok=3RkMMJWWfF9wsRouu6TPZKXonjHpfsX67OkoW6O2lMI%2F0ER3fOvrPUfGjI4GRctkI%2FqLAzICFpZo2FFOH%2FKGdY9O9ftY • Scrum Guide • Brian Marrick, Driving Projects with Examples: A Handbook for Agile Projects • Lisa Crispin, Using Customer Tests to Drive Development • Joshua Kerievsky, Storytest-Driven Development Article • Acceptance Test-Driven Development, http://en.wikipedia.org/wiki/Test-driven_development • Dan North, Introducing BDD • GojkoAdzic, (2011). Specification by Example: How Successful Teams Deliver the Right Software. Greenwich, CT: Manning Publications • Robert C. Marin, GrigoriMelnik: Tests and Requirements, Requirements and Tests: A Mobius Strip. IEEE Software 25 (1): 54-59 (2008) • Ron Jeffries, Essential XP: Card, Conversation, Confirmation

19. For more information • For more information • Adzic, Gojko, Specification by Example: How Successful Teams Deliver the Right Software. Manning Publications, 2011. • Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis, EBG Consulting, 2012. http://www.discovertodeliver.com/ • Matts, Chris, and GojkoAdzic. “Feature Injections: Three Steps to Success.”  http://www.infoq.com/articles/feature-injection-success • North, Dan. “Introducing BDD.”  http://dannorth.net/introducing-bdd/ .