What you need to know about agile and tech comm
•Download as PPTX, PDF•
1 like•296 views
When working in an agile environment, technical writers can face some challenges in planning, workload balancing, and execution. But writers can realize numerous benefits in this environment if they follow a few principles to stay flexible and fully engaged on their project teams. This session provides the top five things you need to know to be a successful technical communicator in an agile environment.
Recommended
Recommended
More Related Content
Similar to What you need to know about agile and tech comm
Similar to What you need to know about agile and tech comm (20)
Recently uploaded
Recently uploaded (20)
What you need to know about agile and tech comm
- 1. WhatYou Need to Know about Agile andTech Comm Alyssa Fox, Micro Focus 4/11/2016TC Dojo Open Session 1
- 2. Benefits of Agile to Writers • Expands writers’ roles on their teams • Improves the quality of documentation deliverables • Helps writers avoid most of the end-of- release-cycle crunch that occurs in waterfall development 4/11/2016 TC Dojo Master Session 2
- 3. Done vs. Done Done
- 4. Lesson #1 4/11/2016 TC Dojo Master Session 4 Use the whole team approach and ensure you are an equal member of the team.
- 5. More Thorough Technical Reviews
- 6. Lesson #2 Include documentation tasks and their reviews within user stories alongside coding and testing tasks. 4/11/2016 TC Dojo Master Session 6
- 7. The Way You Write
- 8. …But Beware…
- 9. Lesson #3 Content comes first, process comes second. 4/11/2016 TC Dojo Master Session 9
- 11. Lesson #4 Capacity planning can make you or break you, especially on multiple projects. 4/11/2016 TC Dojo Master Session 11
- 13. Lesson #5 Don’t focus on “shippable” at the end of the sprint. Focus on “potentially.” 4/11/2016 TC Dojo Master Session 13
Editor's Notes
- Silos among functional areas lead to the whole team not having the same vision of what you are building. These silos cause testing and documentation tasks to lag sprints behind Development, rather than all of the functional areas working together as a team to code, test, and document user stories all within the same sprint. Rather than calling a user story “done,” often a story is called “done” when Development is done coding, and “done done” after the story has been tested and documented. While the “done done” designation sounds silly, it’s descriptive of how the tasks for user stories were previously viewed – that is, two different stages of “done” were used, which goes against the ideals of an agile team. In the whole team approach, the whole team accepts responsibility for completing ALL aspects of each user story (including quality and documentation tasks).
- Speak up in meetings and ask questions to get involved in all areas of the product development. Claim ownership of the technical accuracy of your documentation. Attend and participate in the agile meetings – planning, standup, backlog grooming, retrospective.
- Write doc for a feature in the sprint in which it is developed and tested. This is considered “first draft.” Have SMEs review the doc for technical accuracy and apply the edits before closing the user story. Use the full approval draft later in the release cycle to show context – combination of all the previous doc snippets. Advantages of this approach: Info Dev gets more thorough reviews. The documentation is more technically accurate and higher quality. The team member’s needed capacity for an approval draft is reduced. Multiple approval drafts for multiple books on multiple products isn’t such a big hit all at once on the team member’s time.
- Make your user stories *about the user*. Work with your team to write problem statements and acceptance criteria that focus on solving user pain points and understanding how users will know the problem is fixed. Then, for each user story, everyone knows what problem they’re fixing and why, as well as what the expected behavior is once they fix the problem. The problem statements/acceptance criteria then become the main source for writing the doc, so writing and reviewing the doc should require less time.
- User stories tend to be feature-centric. While it’s important that you understand the pain points your customers are facing, be careful not to get locked into writing only doc for features. Ensure you track overarching work such as fixing bugs, tying together scenarios and best practices with procedures, documentation rework, and production work through doc-only user stories.
- Consider previous sprint estimates. Include vacation and non-sprint responsibilities. Consider planning meetings, customer support, backlog grooming, demos, and retrospectives. Estimate approximately 20% of each team member’s time for these. Ensure Development finishes early so testing and can complete their tasks before the sprint ends. Track your doc-only tasks and user stories in same place as other work so you don’t overbook yourself and so you provide visibility to the team into what you're working on.
- Work with your lead or manager to spread your workload so you can delegate standup meeting attendance to others. Attend meetings that pertain to your highest priority project only. Ask the scrum master to send status emails for the meetings so you know what you missed. Ensure you have a presence on your team so your team doesn’t forget you when you’re not there. Determine when the best time for team kickoffs are and get involved then.
- “Potentially shippable” means for just the part of the product developed in that sprint: The documentation for those user stories is complete and shippable. The UI review for those user stories is complete and changes implemented. The entire book and help system probably are not complete and shippable until some ID-only user stories are complete in the last sprint or even after sprints. The concept(s), procedure(s), and reference(s) necessary for that user story are done. Documentation review by the team is the “acceptance test,” so we must plan time for documentation review in the sprint. Other doc tasks (ID-only user stories) probably are not done.
- What part of the doc needs to be done to go with the part of the product developed in the sprint?