Embed Size (px)
Citation preview
The Truly Agile Technical Writer
David Stula
UA Europe 2015
What is agile?
• Flexibility
• Adaptability
• Discipline
• Cross-functional teams
Scrum meetings• Backlog (pre-)grooming (backlog refinement)
• Sprint planning
• Daily scrum
• Sprint review
• Sprint retrospective
Backlog grooming
• Purpose: Achieve shared understanding of user stories
• Input: epics, ideas, top priority stories
• Output: clear, detailed user stories that the team understands
• Advice: help write the stories!
Scrum meetings
What is a user story?
• Technical communication
• Who (actor), What (action), Why (result)
The AART of user stories
The AART of user stories
• Actor, Action, Result, Test
• Product owner identifies market problems, i.e. actor and
result (who needs to achieve what)
• Allows the team to be creative and come up with the right
action (how will they achieve the result)
• Example: band wants to share songs
Courtesy Fred Williams
williamstechnical.eu
Traditional user story
As a band member, I want to upload a song to SoundCloud
so that I can share it with my band’s fans.
The AART of user stories
User story breakdown
• Actor: band member
• Result: share a song with fans
• Action: upload it to SoundCloud, Facebook, YouTube, MySpace
• PO lets the team come up with different creative solutions, decides on the best one.
The AART of user stories
Revised user story
Dave the Drummer uploads a song to SoundCloud to
share it with his band’s fans.
The AART of user stories
Testing the result
• How does the actor achieve the result?
• What are the steps to perform the action?
The AART of user stories
Example of a test
1. Go to soundcloud.com.
2. Log in.
3. Click Upload a new song.
4. Choose the song you want to share.
5. Click OK.
The song starts uploading. The upload page shows the upload progress.
The AART of user stories
Non-functional requirements
• What permissions do I need?
• What hardware do I need?
• What format shall the file be in?
The AART of user stories
Backlog grooming outputs• User story
• Actor
• Action
• Result
• Tests
• Non-functional requirements
• Prep work that needs to be done
• Technical limitations research
• Wireframes or paper prototypes of the UI
Scrum meetings
Sprint planning
• Two parts
• Why & What – final agreement on the stories, estimating
• How – tasks for the team, work division
• Input: user stories in AART form
• Output: estimates, tasks, team commitment
• Advice: participate in estimating!
Scrum meetings
Estimating stories
• Play planning poker with the team.
• Estimate documentation tasks separately.
• T-shirt sizes: S, M, L, XL
• Keep track of how much work you can complete in a sprint.
• Delegate documentation work to the team.
• Refuse to commit a story where documentation work exceeds this limit.
Sprint planning
Sprinting
• Write your docs outlines and drafts ASAP
• Give them to the product owner for completeness review
• Write/rewrite/edit as development progresses
• Attend daily meetings
• Give finished docs to team for accuracy review
Sprinting – typical challenges
• No access to product
• No team access to docs
• Not enough information – work with testers, they also don’t have much work at the
beginning of the sprint
• Provide input on UI design
Daily scrum
• Answer the 3 questions
• Don’t go into too much irrelevant detail
• Ask how impediments the team has will affect the user
Scrum meetings
Sprint review
• Not absolutely necessary for TW
• Review UI text
• Show the completed documentation
Scrum meetings
Sprint retrospective
• Identify any process or communication issues
• If docs not finished, analyze why
• Don’t forget to mention what went well
Scrum meetings
Retrospective – typical challenges
• PO does not have time to review your documentation draft
• Write it earlier or do the review together – guide them through, explain what you meant
• Developers don’t have time to review documentation
• Make sure you include review time into estimates
• Documentation was not finished in time
• Delegate work or refine estimates
Scrum meetings
Other challenges• Context – connecting more stories together into a workflow
• Do usability testing, you’ll see the gaps
• Docs as separate stories/tasks
• Maintenance and updates
• Make sure you think about them when grooming and estimating
• Publishing
• Choose adequate tools and process, refine as you go
• Wiki is ideal
• One sprint before release dedicated to publishing work
Supporting multiple teams
• You can comfortably support only 2
• If more than 2, skip meetings
• Review
• Second part of planning
• Once team realizes documentation is a must, they will be
willing to help
• Get a laptop and move between offices, but don’t multitask
Conclusion
• Good user stories that reflect market problems and needs are key
• Don’t be afraid of guessing
• Constantly reflect on what you do and make changes
• Teach the team about what you do and learn about what they do
Discussion time
• How many teams do you support?
• What do your user stories look like?
• Which meetings do you attend?
• How do you estimate the effort/time needed for documentation?
