GET HOME ON TIME! - Agile Alliance · 2/14/2012 2 InsightfulSolutions :: Innovative Technologies Description. • Do not waste your time building the wrong features. Learn to write

2/14/2012

1

Insightful Solutions :: Innovative Technologies


HOW USING EXCELLENT EXECUTABLE

REQUIREMENTS CAN HELP YOU DO THAT!

GET HOME ON TIME!

2

2/14/2012

2


Description.

• Do not waste your time building the wrong features. Learn to write

executable requirements that the business, developers, and testers can

understand. See how executable requirements can be created in difficult

situations such as refining vague requirements, and helping product

owners use “one voice.” Learn the principles of building executable

requirements and acceptance criteria that capture customer value.

3


Outline.

• Introduction/Agenda (5 minutes)

• Review what Bad Look like(10 minutes)

• Review what Good can Look like(10 minutes)

• Team Breakout write 1st Happy Path AC scenario(s) (10 minutes

• Review Happy Path Scenario(10 minutes).

• Team Breakout write 2nd UnHappy Path AC scenario(s) (10 minutes)

• Review non Happy Path Scenarios (10 minutes)

• Put AC into automated tests (15 minutes)

• Q and A (Wrap up) (10 minutes)

4

2/14/2012

3


What audience learns

• Practice writing good Acceptance Criteria

• Practice Collaborating with Testers defining Automated

AC.

• Practice techniques to create common understanding

with Product owners

• Introduce attendees to automation tools to add to your

toolkit.

• Tool specific templates for use between Product

Owners, Business Analysts, Testers and Developers.

5


Agenda

• What bad looks like

• How it happens

• Better ways

• Example

2/14/2012

4


Bad Requirements Examples

• Lengthy

• Unfocused

• Ambiguous

• Verified

Manually


Bad requirement might look like:

2/14/2012

5


A COMMON SCENARIO

DEMO


Architecture documents

Architecture Document

Development Policies

Requirements Documentation

2/14/2012

6


QA documents

Test Plans

Use Cases

Detailed Status Repots


Developers Deliver

2/14/2012

7


Rules

• 1 minute discussion of scenario.

• Because Product Owner is busy with other

meetings, take 5 minutes and create your

written acceptance criteria for this feature.

• After 5 minutes we review the AC.


Actual Request

• Frequent Traveler wants to be notified when

there are deals in his favorite area.

• The traveler should be able to tell us what

“deal” means to her, and what her favorite

area is.

• If the traveler can’t tell us then we need to be

able to figure that out without his input.

2/14/2012

8


SO, WHAT HAPPENED?


What Issues Can we identify?

• Working in isolation

2/14/2012

9



• Speaking different languages



• Covering too much!

2/14/2012

10



• Limiting to one type of artifact


A Better Strategy

Our strategy for executable requirements means

we have to know when the requirements are

met. This is achieved by:

2/14/2012

11


Tips for Close Collaboration

• Collaboration on acceptance criteria between

customer and team



• Get the team together in the same room

2/14/2012

12



• Get the remote teamtogether using Video

conference/Skype



• Get the team together using Collaboration tools

like Dabbleboard

2/14/2012

13



• Get the team together just using a Phone call



• Confirm agreement with lite documentation

2/14/2012

14



– Collaboration on acceptance criteria between

customer and team

– Get the different parties together

• Same room

• Video conference/Skype

• Collaboration tools like Dabbleboard

• Phone call

– Confirm agreement with lite documentation


Speak the Same Language

• Capture the Common Objective

� “Elevator Statement”/Theme

2/14/2012

15



• Create a Shared workspace

� Physical

� Wiki



– Capture the Common Objective

• “Elevator Statement”/Theme

– Create a Shared workspace

• Physical

• Wiki

– Keep the Team Consistent

2/14/2012

16


Remove Ambiguity

• Provide Additional Context By Having the

Conversation


Remove Ambiguity

• Provide Additional Context By Creating an

Overview

2/14/2012

17


Remove Ambiguity

• Provide Additional Context by Supplementing

with Picture(s) or Diagrams


Remove Ambiguity

• Provide Additional Context by Identifing the

Actor(s) or Persona(s)

2/14/2012

18


Remove Ambiguity

• Provide Additional Context by Mocking the UI

with Wireframes


Remove Ambiguity

• Provide Additional Context

– Have the Conversation

– Create an Overview

– Supplement with Picture(s) or Diagrams

– Identify the Actor or Persona

– Mock the UI with Wireframes

2/14/2012

19


Insightful Solutions :: Innovative TechnologiesFrom the blog “Pragmatic Agilist” by Elena Yatzeck

http://pagilista.blogspot.com/2010/11/comprehensive-documentation-strikes.html

Executable

Requirements

2/14/2012

20


Manually

Executed Test

Scripts

UAT

Manually Executed Test

Scripts

Layer Your Tests

• Traditionally, your test layers might look a

lot like this:


UAT

Manually Executed Test

Scripts

Layer Your Tests - More

• Developers may embrace Unit Testing

Unit Test

2/14/2012

21


UAT

Manually Executed Test Scripts

Better Yet…

Unit Test

Automated Functional Tests

Manual Tests

Primarily

Exploratory

Tests


Type of Executable Requirements

Automated Functional Tests

Acceptance Criteria

Integrated into build

activityUI Tests

2/14/2012

22


Type of Executable Requirements

• Unit Tests are created by developers and are for

developers• See “Test Driven Development by Example” by Kent Beck, or “Clean Code”

by Robert Martin


• Executable Requirements are a time saver by

helping IT and Business work more closely

together

How does this help?

2/14/2012

23


How does this help?


helping the team get the feature right the first

time


How does this help?


lowering the cost of iterating

2/14/2012

24


How does this help?


reducing maintenance and “end of project”

tails to regress


How does this help?

• team up to improve software without

the big cost of manual regression testing,

reducing cost for introducing new features

2/14/2012

25


How does this help?

• team up to improve software without the

big cost of manual regression testing, reducing cost

for Fixing defects


How does this help?

• team up to improve software without the

big cost of manual regression testing, reducing cost

for Refactor code

2/14/2012

26


Good Executable Requirements

• Understandable to developer

• Understandable to business

• Unambiguous

• Automated

• Run frequently


Defining Executable Requirements

• Demo

• Scenario:

– Existing Application

– Eric – Product Owner/Customer

2/14/2012

27


Let’s Redo this Request

• Frequent Traveler wants to be notified when

there are deals in his favorite area.

• The traveler should be able to tell us what

“deal” means to her, and what her favorite

area is.

• If the traveler can’t tell us then we need to be

able to figure that out without his input.


Rules

• 5 minutes initial discussion asking questions of

product owner, interactively creating User

Story with some AC (written).

• Collaborate with Team including developers as

we write the Executable requirements for

story.

2/14/2012

28


Demo


Summary

• Executable requirements:– Written to what the business needs

– Come about through a different process

– Increase value throughput

– Remain relevant through automation

• References…– Lean-Agile Acceptance Test-Driven Development by Ken Pugh

– Test Driven .NET Development with FitNesse by Gojko Adzic

– Fitnesse (http://fitnesse.org/)

– Selenium (http://seleniumhq.org/)

– Cucumber (http://cukes.info/)

2/14/2012

29


Thank You

• Speaker Contact Information

– Eric Landes (AgileThought)

• [email protected]

• http://www.linkedin.com/in/ericlandes

• http://twitter.com/ericlandes

• http://agilethought.com

• Please provide feedback on ways this

presentation can be improved


Erics Bio

• Eric Landes has been involved with the IT industry for

close to 20 years. He has been using Agile methods for

the past 6 years, in a Team Lead/Project Manager

capacity. He has presented on Kanban, automated

acceptance tests, and other agile topics at different

agile conferences, and user group meetings. Eric has a

CSM and is a Microsoft MVP. For more information,

check out his web site, http://ericlandes.com

58

Documents

GET HOME ON TIME! - Agile Alliance · 2/14/2012 2 InsightfulSolutions :: Innovative Technologies Description. • Do not waste your time building the wrong features. Learn to write