This document discusses progressive elaboration in agile software development projects. It involves continuously improving and detailing a project plan as more detailed and specific information becomes available. User stories are used to describe features from the perspective of an end user. Acceptance test-driven planning involves defining acceptance criteria for stories in a Given-When-Then format. Behavior-driven development specifies behavior before writing code and uses testing to guide design and ensure code works as intended. User testing helps evaluate usability and may expose new acceptance criteria.

1. Progressively elaborating upon
Progressive Elaboration & Specification
part 6
Agile Analysis & Design The Trilogy

2. Bob Vincent
• Product Manager
• XP, Scrum, Lean software projects since 2004
• CSPO, CSM

3. “If a man will begin with certainties,
he shall end in doubts;
but if he will be content to begin with
doubts, he shall end in certainties.”
The Proficience and Advancement of Learning (1605)
Sir Francis Bacon

4. Progressive Elaboration
"Because of the potential for change, the project
management plan is iterative and goes through
progressive elaboration throughout the project's
life cycle. Progressive elaboration involves
continuously improving and detailing a plan
as more-detailed and specific information
and more accurate estimates become
available."

5. Backlog
Epics
Stories
-may also have UI mockups/Prototypes/User research & other artifacts leading into release.
-time for Qualitative research: discover unmet needs

6. Agile User Stories
• Describes an objective & motivation
• Does NOT describe the solution
• It’s pretty brief - “a promise for a conversation”

7. Three critical aspects of user stories
• Card
• Conversation
• Confirmation
“Extreme Programming Installed” 2000

8. Story Title
• In order to [provide value]
• [persona(s)]
• want [a feature]

9. Rank the backlog - just enough to meet objectives (release date, MMF)

10. Sprint / Iteration / Rolling-wave Planning (V1 experimentation)

11. Acceptance Test-
Driven Planning
Process Agnostic Defining
DONE
Participants:
Product Owner
Testers
Devs
UXers
define Done
Sprint / Iteration / Rolling-wave Planning (V1 experimentation)

12. Acceptance Test-Driven Planning
GIVEN [an initial context or condition]
WHEN [persona] [does something]
THEN [expected behavior occurs]
-PO may have ATs coming in; create more in planning
-GWT format forces ATs to be broken-down somewhat consistently
-too many ATs in a story is a smell that the story is too large

13. Dev + PO + [Designers].

14. Behavior/Test-Driven
Development
Process Agnostic
Participants:
Testers
Devs
UX
define behavior (solution specific) before code - think thru for better design
write more efficient code

15. Behavior/Test-Driven Development
• Specify behavior (test) before writing code
• Test all the time
• Refactor
• Design all the time
• Code design needs to flex & grow
• Add spec/tests for new emergent behavior
focusing on behavior rather than state = less brittle
-difficult to predict what comes out of emergent design / expensive to try

16. User testing A
B
Usability testing goals:
• Effectiveness
• Efficiency
• Satisfaction

17. May expose new ATs. too many==smell

18. Task
Opportunity for more user testing (task testing)
PO verifies ATs - proclaims DONE.

19. “An interactive session with working software
is worth a thousand meetings.”

20. Backlog
Epics
Stories++
May expose opportunities for improvement (new stories).
Identify features with high risk of iteration & rank them high.

22. automating all this

23. cucumber + rspec

24. Thank You!