Making Team Flow and Progress Business Readable€¦ · •Started practicing BDD in 2009...

Post on 07-Jun-2020

5 views 0 download

transcript

COPYRIGHT 2011, TECHTALK - WWW.TECHTALK.AT

Agile 2011 Salt Lake City, 10th of August 2011

Making Team Flow and Progress Business Readable

CHRISTIAN HASSA ch@techtalk.at, @chr99ha

2

My context of work

• Project contract development and agile consulting (50+ people)

• Started practicing BDD in 2009

•Initiated SpecFlow BDD for .NET

•SpecLog Gherkin based living documentation systems

www.specflow.org

www.speclog.net

3

Our BDD cycle vision

Product

Backlog

Epic

User Story

Epic

User Story

User Story

User Story

User Story

desired

effects Roadmap

derive scope from goals

Sprint

Backlog

US

US

US

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

UI Scribbles as key examples

Acceptance Criteria as key examples

illustrate using examples

Given

When

Then

Au

tom

atio

n

{ … }

{ … }

{ … }

refine the specification

executable specification

F

F F

F F F

F F

AC

AC

AC

AC

AC

living documentation

Features “done”

merge when

accepted

validate continuously

automate without changing the specification

Current

sprint

AC

US

AC

AC

AC

US

AC

AC

AC

US

AC

AC

possible next product increments

red-green-refactor, ATDD

story

maps

4

Deriving scope from goals vision

Product

Backlog

Epic

User Story

Epic

User Story

User Story

User Story

User Story

desired

effects Roadmap

derive scope from goals

Sprint

Backlog

US

US

US

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

UI Scribbles as key examples

Acceptance Criteria as key examples

illustrate using examples

Given

When

Then

Au

tom

atio

n

{ … }

{ … }

{ … }

refine the specification

executable specification

F

F F

F F F

F F

AC

AC

AC

AC

AC

living documentation

Features “done”

merge when

accepted

validate continuously

automate without changing the specification

Current

sprint

AC

US

AC

AC

AC

US

AC

AC

AC

US

AC

AC

possible next product increments

red-green-refactor, ATDD

story

maps

5

Mapping our product backlog

6

Documenting completed user stories vision

Product

Backlog

Epic

User Story

Epic

User Story

User Story

User Story

User Story

desired

effects Roadmap

derive scope from goals

Sprint

Backlog

US

US

US

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

UI Scribbles as key examples

Acceptance Criteria as key examples

illustrate using examples

Given

When

Then

Au

tom

atio

n

{ … }

{ … }

{ … }

refine the specification

executable specification

F

F F

F F F

F F

AC

AC

AC

AC

AC

living documentation

Features “done”

merge when

accepted

validate continuously

automate without changing the specification

Current

sprint

AC

US

AC

AC

AC

US

AC

AC

AC

US

AC

AC

possible next product increments

red-green-refactor, ATDD

story

maps

7

Maps of living documentation

8

Guarded with automation

9

Implementation flow vision

Product

Backlog

Epic

User Story

Epic

User Story

User Story

User Story

User Story

desired

effects Roadmap

derive scope from goals

Sprint

Backlog

US

US

US

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

Acceptance

Criteria

UI Scribbles as key examples

Acceptance Criteria as key examples

illustrate using examples

Given

When

Then

Au

tom

atio

n

{ … }

{ … }

{ … }

refine the specification

executable specification

F

F F

F F F

F F

AC

AC

AC

AC

AC

living documentation

Features “done”

merge when

accepted

validate continuously

automate without changing the specification

Current

sprint

AC

US

AC

AC

AC

US

AC

AC

AC

US

AC

AC

possible next product increments

red-green-refactor, ATDD

story

maps

10

Collecting key examples

Lo-fi UI scribbles

Sample data

Existing artifacts Samples

Business rules

11

Deriving intentions from examples

Collecting examples and deriving intentions requires collaboration

between the „three amigos“

13

Formalizing scenarios (AC)

scenarios = abstract acceptance criteria illustrated with examples (AC)

14

Tasks are not business readable

Create bookings for a fixed time loop on

15

… but scenarios (AC) are

16

Transparency for stakeholders

In Progress

17

Current sprint report: all sprint scenarios

18

Starting with first scenario (AC)

19

Finishing the first scenario (AC)

20

Progressing scenario after scenario

21

Progressing scenario after scenario

22

Progressing scenario after scenario

23

Implementing user stories in parallel

24

First user story ready for testing

25

Testing can start even earlier

26

Already done work can break again

27

Already done work can break again

28

See what is temporarily not working

29

Lessons learned

Track progress of scenarios accessible for all project stakeholders

•builds trust: know what’s going on

•shows what’s ready to test: completed, temporarily not working

•helps involving business into BDD cycle

30

Lessons learned Align tasks with scenarios task planning after formalization of scenarios

• helps team with task planning (some teams even drop task planning)

• helps team limiting WIP on scenario level (not just user story level)

• yields earlier testable user stories (partial finished, prioritized scenarios)

COPYRIGHT 2011, TECHTALK - WWW.TECHTALK.AT

Contact for more info CHRISTIAN HASSA

EMAIL: CH@TECHTALK.AT

TWITTER: @CHR99HA

CUCUMBER/GHERKIN TOOLS:

WWW.SPECFLOW.ORG

WWW.SPECLOG.NET

WWW.CUKES.INFO