The presentation helps you apply useful principles from agile methodologies for developing technical documentation. It also highlights the features common to agile development processes and helps you understand user stories and learn to translate user stories into task-oriented topics. You also learn to use various collaboration tools that can facilitate writing.

1. Technical Writing in an Agile
Development Environment
A Writer’s Perspective

2. 2
Objectives
 Learn to apply useful principles from agile
methodologies
 Highlight the features common to agile
development processes
 Understand user stories and learn to translate
user stories into task-oriented topics
 Learn to use various collaboration tools that can
facilitate writing
 Learn to be adaptive

3. 3
The Agile Parable
A pig and a chicken are walking down a road. The
chicken looks at the pig and says, "Hey, why
don't we open a restaurant?" The pig looks back
at the chicken and says, "Good idea, what do
you want to call it?"
The chicken thinks about it and says, "Why don't
we call it 'Ham and Eggs'?"
"I don't think so," says the pig, "I'd be committed
but you'd only be involved.”

4. 4
Who’s Who in Agile

5. 5
Scrum Origins
 The new product development game - Tekeuchi
and Nonaka
 A group of 17 individuals got together in
Colorado in 2001 to form the Agile manifesto.
 Jeff Sutherland and Ken Schwaber
 Initial definitions of Scrum at OOPSLA 96
 Not just for trivial projects
 FDA-approved, life-critical software for x-rays and MRIs

6. 6
The Agile Manifesto
Over

7. 7
Phases of Scrum– From Concept to
Execution

8. 8
The Scrum Development Process
Daily Scrum
•Hosted by ScrumMaster
•Attended by all, but Stakeholders
don’t speak
•Same time every day
•Answer: 1) What did you do
yesterday? 2) What will you do
today? 3) What’s in your way?
•Team updates Sprint Backlog;
Scrum Master updates Blocks List
POPO
Product Owner:
Sets priorities
SMSM
ScrumMaster:
Manages process,
removes blocks
TT
Team (Pigs):
Develops
product
SHSH
Stakeholders
(Chickens):
observe & advise
Key Artifacts
Product Backlog
•List of requirements & issues
•Owned by Product Owner
•Anybody can add to it
•Only Product Owner prioritizes
Product Backlog
•List of requirements & issues
•Owned by Product Owner
•Anybody can add to it
•Only Product Owner prioritizes
Sprint Goal
•One-sentence summary
•Declared by Product Owner
•Accepted by team
Sprint Goal
•One-sentence summary
•Declared by Product Owner
•Accepted by team
Sprint Backlog
•List of tasks
•Owned by team
•Only team modifies it
Sprint Backlog
•List of tasks
•Owned by team
•Only team modifies it
Blocks List
•List of blocks & unmade
decisions
•Owned by ScrumMaster
•Updated daily
Blocks List
•List of blocks & unmade
decisions
•Owned by ScrumMaster
•Updated daily
Increment
•Version of the product
•Shippable functionality (tested,
documented, etc.)
Increment
•Version of the product
•Shippable functionality (tested,
documented, etc.)
Key Meetings
Sprint Planning Meeting
•Hosted by ScrumMaster; ½-1 day
•In: Product Backlog, existing
product, business & technology
conditions
1. Select highest priority items in
Product Backlog; declare Sprint Goal
2. Team turns selected items into
Sprint Backlog
Out:: Sprint Goal, Sprint Backlog
Sprint Review Meeting
•Hosted by ScrumMaster
•Attended by all
•Informal, 4-hour, informational
•Team demos Increment
•All discuss
•Hold retrospective
•Announce next Sprint Planning
Meeting
Product
Backlog
Product
Backlog
Development Process
IncrementIncrement
Sprint Planning Meeting
Daily Scrum
Daily Work
Sprint
Goal
Sprint
Goal
Sprint
Backlog
Sprint
Backlog
Blocks
List
Blocks
List
ProductProduct
Sprint Review Meeting
Sprint:
15-30 days
each
Product
Backlog’
Product
Backlog’
Increment’Increment’
Copyright 2004, William C. Wake, William.Wake@acm.org, www.xp123.com

9. 9
Agile System Development Lifecycle

10. 10
Overlapping Development in Scrum

11. 11
Waterfall vs. Agile

12. 12
Making the Transition
 How can I adapt myself to Scrum?

13. 13
Design Documents
 Moving from specs to user story documents
 Shorter, more fluid documents
 Allows for easier refinement and rework upon
customer feedback
 Helps the writers to not get bogged down in lengthy
specs

14. 14
User Stories- What is it?
 A software system requirement
 Defines what is to be built
 Prioritized, make up the backlog
 Stories may be related together as “features” or
“themes”

15. 15
User Stories
As a … < role> …
I want … <short description of feature> …
So that … <value or why need functionality>
…
Examples:
 As a sales manager I want to view the sales report so
that I can know the sales for this quarter.
 As a regular traveler I want my cell-phone to wake me
up at a set time so that I do not need to pack an alarm
clock.

16. 16
Acceptance Criteria
A common acceptance criteria
template:
Given … <some initial context > …
When … <an event occurs> …
Then … <ensure some outcomes> …
Given my cell-phone is switched off when
the time for my alarm is reached then turn
the cell-phone on and sound the alarm.

17. 17
Topic-Oriented Writing

18. 18
Topic-Oriented Writing
 Authoring concise, self-contained units of
information about a specific topic
 Concept
 Task
 Reference

19. 19
Using Minimalism
 Choose an action-oriented approach to your
documentation
 Promote learning by doing rather than by
reading
 Evaluate what to trim and why (‘Just enough’
documentation)
 Focus on troubleshooting advice
 Identify opportunities to replace text with
graphics

20. 20
Benefits of Using Minimalism
 Pushes us to be more user-focused
 Makes us look out for redundant information
 Drives us to cut costs while delivering better
information
 Portrays us like we understood our role better

21. 21
Collaborate
 Use a collaboration tool (e.g. wiki)
 Attend daily scrum meetings
 Be detailed and specific when you are seeking
information

22. 22
Using Wikis
Image Copyright @ Atlassian

23. 23
Best Practices for Wiki Implementation

24. 24
Using Wikis as an Input for Docs

25. 25
Backlog is Your Friend
 The Backlog in Scrum is the Technical Writer’s
best friend.
 Work with the dev team to understand the tasks
 You can re-plan a Sprint in the mid-Sprint
 Allocate some time in the Sprint for
maintenance and patches.
 Backlog is NOT DONE if the end-user
documentation is not complete

26. 26
Document Reviews in Scrum
 Use drafts
 Write doc for a feature that is developed and
tested in the Sprint
 Have Dev/QA review the doc for technical
accuracy before closing the user story
 Make the required edits
 Publish IT
 Present the doc to the PO in the exit meeting

27. 27
Before the Release
 Have a stabilization sprint for
the document cleanups,
versioning, and help
integration.

28. 28
Vertical Doc Team Structure – Writer
Aligned to the Scrum Teams
Write
r
Product ABC Product XYZ Released products Legacy
Product
s
Feature A Feature
B
Feature
A
Feature
B
Feature
A
Feature B Bugs/
Minor
Fixes
Patche
s
Life
Support
Steve
Maria
Marc

29. 29
Scrum in Action

30. 30
The Benefits of Writing in an Agile
Environment

31. Questions?

32. 32
Sources and Bibliography
 Agile Estimating and Planning, Mike Cohn, Prentice Hall, 2006.
 Agile Project Management with Scrum, Ken Schwaber, Microsoft Press,
2004.
 Writing Effective Use Cases, Alistair Cockburn, Addison Wesley, 2001.
 Agile Development: Challenges in Transforming Technical Communications
Departments, Mike Wethington.
 “An Overview of Scrum”, Mike Cohn,
http://www.mountaingoatsoftware.com/presentation/30-an-overview-of-scrum
, 2008
 “Writing End-User Documentation in an Agile Development Environment,”
Anne Gentle & Tana Berry,
http://justwriteclick.com/2007/07/02/writing-end-user-documentation-in-an-agile-de
, 2007.

33. Thank You