Demystifying the Agile experience... Most Agile guidelines and training treat all scrum team members as equal co-owners of all aspects of the development process and assume a pure and established Agile environment. Many, arguably most, real world Agile implementations, are less than pure, stable, or ideal. Most require additional considerations for non-development team members such as content developers (technical writers), and to some extent, testers. I created "Guidelines for Content Development in an Agile Scrum Environment" in an effort to addresses the many unique challenges facing content developers who are transitioning from a traditional waterfall model to Agile. I based the original presentation on my research into Agile Lean, Scrum, and Kanban development methods. I supplemented it with Agile management, Agile scrum team member, and Agile ScumMaster certification training. I balanced my research and training against 12 years experience managing technical content development projects in the high tech industry. Finally, I refined this material over a 2 1/2 year period of real world application with a team of 60+ content developers assigned to scrum teams using development processes that ranged from near textbook Agile to "Agile in Name Only." I won't pretend these Guidelines contain everything you need to know about content development in all Agile environments, but if your content development team is new to Agile or is moving to Agile in the near future, I'm certain this will help you make the transition. Best Regards, Dave Derrick Certified Agile ScrumMaster Certified Agile Scrum Product Owner Senior Project Manager, Technical Documentation, Marketing Communications, & Vendor Relationships

1. Guidelines for Content
Development in an Agile
Scrum Environment
Copyright © 2015, Dave Derrick

2. First Words
Don’t be afraid of moving to Agile. A poor Agile environment is no
worse than a poor waterfall environment. A good Agile environment
will make you feel like a member of the team.
Know the Definition of Done. It is your new best friend. Make it work
for you.
Help your scrum team treat documentation as a component of the
product. Everything else will fall into place.
Copyright © 2015, Dave Derrick
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.
Copyright © 2015, Dave Derrick
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.
Copyright © 2015, Dave Derrick
4

5. Tool and Content Delivery
Considerations
 Agile Scrum methodology may demand different tools,
deliverables, and delivery methods to enable Content Developers
to support sprint development cycles. For example:
o Use more streamlined tools, such as 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/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.
Copyright © 2015, Dave Derrick
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.
Copyright © 2015, Dave Derrick
6

7. Writer/Scrum 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.
Copyright © 2015, Dave Derrick
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.
Copyright © 2015, Dave Derrick
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.
Copyright © 2015, Dave Derrick
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.
Copyright © 2015, Dave Derrick
10