making team flow and progress business readable€¦ · •started practicing bdd in 2009...
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 [email protected], @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: [email protected]
TWITTER: @CHR99HA
CUCUMBER/GHERKIN TOOLS:
WWW.SPECFLOW.ORG
WWW.SPECLOG.NET
WWW.CUKES.INFO