2. First Words
Don’t be afraid of Agile. Poor Agile practices are no worse than a poor
waterfall practices. Good Agile practices will make you a member of the
team.
If you help your Scrum team treat documentation as a component of the
product, everything else will fall into place.
Know the Definition of Done. It is your new best friend.
2
3. General Considerations
General considerations for Content Developers and information content
development in an Agile Scrum environment:
o Content Developers should engage with all development scrum teams.
o Content Developers should participate as fully accountable team members in all sprints
for which there are information content deliverables.
o Content Developers may function as stakeholders for sprints in which there are no
information content deliverables.
o Individual Content Developers may be required to belong to multiple scrum teams
(persistent, not necessarily dedicated).
o Content Developers may need to form a separate doc scrum team to track
documentation work across development scrums (similar to a scrum of scrums).
o Documentation will probably require one to two sprints prior to product release for doc-
specific tasks such as online help building and testing, final reviews, content delivery
preparation, etc.
3
4. Staffing Considerations
Agile methodologies may demand additional staffing commitments to
enable Content Developers to support multiple scrum teams and to
counteract the additional meeting requirements and increased
development velocity.
o Pure Agile expects dedicated resources for each scrum team – one content
developer, one scrum team.
o Most Content Developers will belong to multiple scrum teams.
o Most Content Developers can belong to and effectively participate in two to
three scrum teams.
o Content Developers continuously engaged with three or more scrum teams can
keep up for some amount of time, but may “burn out” over time.
o ScrumMasters can help mitigate staffing shortfall by scheduling common,
shared, area-based planning meetings and demos or by coordinating sprint
planning meetings and demos to allow team members who belong to multiple
scrum teams to attend.
4
5. Content Delivery Considerations
Agile Scrum methodology may demand different tools, deliverables, and
delivery methods to support sprint development cycles. For example:
o Use more streamlined tools, such as HTML or XML, for online content and
online help.
o Increase use of Wiki pages, blogs, user forums, and other dynamic
alternatives to for online content.
o Reduce and streamline all content types.
If delivery methods and platforms are changed, Content Developers must
help set and manage internal and external customer expectations.
Content Developers must be trained in minimalism and structured
authoring to support a more Agile approach.
5
6. Scrum Team Recommendations
Treat documentation as a component of the product.
Include documentation tasks with development tasks.
Preplan documentation tasks with development tasks.
o Schedule pre-planning meetings to ensure documentation (and other)
resources are available if needed for the next sprint.
Include documentation in the “Definition of Done.”
o A user story should not be considered done until the associated
documentation is written, reviewed, edited, tested, and updated accordingly.
Include documentation as part of sprint demos and evaluate
documentation tasks and progress in retrospectives.
6
7. Writer/Team Recommendations
Content Developers should engage with all scrum teams.
Content Developers may belong to multiple scrum teams.
Content Developers generally should not belong to more than two to
three scrum teams each.
Content Developers should participate in pre-planning meetings, planning
meetings, daily stand-ups, demos, and retrospectives as team members
for all sprints that require product doc deliverables.
Content Developers may attend only the sprint planning meetings and
demos as stakeholders for sprints that do not require product doc
deliverables, but should attend those meetings at a minimum.
Content Developers are responsible for tracking documentation user
stories in either the pre-planning or retrospective phase.
7
8. Writer Recommendations
Treat documentation as a component of the product.
Include documentation tasks with development tasks.
Preplan documentation tasks with development tasks.
Create documentation user stories and tasks for applicable sprints in
conjunction with scrum teams.
Create documentation and online help prototypes using wireframe
templates for applicable user stories in conjunction with the scrum team.
Prioritize doc-related issues in sprint backlogs and use the same
burndown tracking methods as dev and test.
Use the same project tracking tool as developers (Rally, JIRA, etc.) to track
progress.
8
9. Writer Recommendations (continued)
Streamline documentation processes.
Reduce and simplify documentation deliverables.
Streamline or eliminate documentation plans.
Adopt new tools and delivery methods to help improve velocity.
Auto-generate and reuse documentation whenever possible.
o Auto-generate content using Javadoc, Doxygen, HeaderDoc, Sandcastle, Ddoc,
JSDoc, etc.
o Reuse or leverage engineering, marketing, customer support, or other
pertinent collateral.
Plan doc-specific sprints for the end of the release (Epic) life-cycle for book
and online help building and testing, check-ins, publishing, and other final
production and delivery tasks.
9
10. Writer Recommendations (continued)
Consider forming a documentation scrum team (scrum of scrums) to
coordinate and manage doc progress and doc-specific tasks and issues such
as:
o Book building.
o Online help creation.
o Non-development content, such as release notes, compliance material, etc.
Each doc scrum team should have a Product Owner who manages the backlog
and priority for docs.
Each doc scrum team should have a ScrumMaster to manage the
documentation scrum team and act as a representative in other product
scrums of scrums.
Doc scrum teams should use standard Agile methods and tools to organize
sprints, track progress, and produce deliverables.
10
