Info dev flexibility in agile
Upcoming SlideShare
Loading in...5
×
 

Info dev flexibility in agile

on

  • 840 views

This presentation helps technical communicators face challenges in agile planning and execution. It’s increasingly common for writers to work on multiple agile teams. The session includes tips for ...

This presentation helps technical communicators face challenges in agile planning and execution. It’s increasingly common for writers to work on multiple agile teams. The session includes tips for better communication and teamwork on your agile team, with the goal of a “whole team approach” in mind.

Statistics

Views

Total Views
840
Views on SlideShare
700
Embed Views
140

Actions

Likes
2
Downloads
29
Comments
0

3 Embeds 140

http://lanyrd.com 106
http://eventifier.co 28
https://twitter.com 6

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Info dev flexibility in agile Info dev flexibility in agile Presentation Transcript

  • Bending Without Breaking:Info Dev Flexibility in AgileAlyssa FoxDirector, Information Developmentalyssa.fox@netiq.com713-418-5334
  • © 2013 NetIQ Corporation. All rights reserved.2Making the Transition• Moving from PRDs to backlogs– Requirements expressed as user stories in the backlog– Prioritized by value, cost, knowledge, and risk– Estimated in “relative-effort” terms by the team• Moving from specs to user stories– Shorter, more fluid “documents”– Easier refinement and rework from customer feedback– Benefits from good acceptance criteria
  • Setting the Stage:The Whole Team Approach to Quality View slide
  • © 2013 NetIQ Corporation. All rights reserved.4The Scrum Team• Product Owner• Scrum Master• Development Team– Dev– QE– ID View slide
  • © 2013 NetIQ Corporation. All rights reserved.5The Whole Team Approach• The Old Way– Divisions among functional areas may mean that the wholeteam doesn’t see the same vision of what we’re building.– QE sees themselves as sole guardians of quality.– Documentation is sole responsibility of ID team.– QE and/or ID might lag sprints behind Dev.– “Done” and “Done Done”
  • © 2013 NetIQ Corporation. All rights reserved.6The Whole Team Approach• The New Way– The whole team understands exactly what we are (and arenot) building.– The whole team accepts responsibility for completing ALLaspects of each user story (including quality anddocumentation tasks).– The whole team acknowledges that the user story is not doneuntil it is tested, all stop-ship bugs are fixed, and it isdocumented.– Quality and documentation tasks occur within the same sprintas development tasks, not lagging behind.– “Not Done” and “Done”
  • © 2013 NetIQ Corporation. All rights reserved.7Ways to Get There• Unit testing• Automated acceptance and regression testing• Including QE and ID in estimates• Test-driven development• Fixing bugs within sprints• Help in other areas when your tasks are done for a sprint(automating test cases, usability testing, setting up environmentsfor others, writing first drafts of documentation, backlog grooming)– Note that resource constraints might mean you work on anotherproject once done in this project’s sprint.
  • © 2013 NetIQ Corporation. All rights reserved.8Swarming• Making QE and ID truly part of the Eng team means giving themthe support they need to adapt to the pace of agile development.• Ensure you are developing vertical slices during sprints (back-end, middle, UI), rather than one component per sprint.• Feature testing, regression testing, and documentation occurduring the sprint. Not just at the end of the sprint or in the nextsprint.• If you have a testing or doc crunch at the end of the sprint, youare doing something wrong. Find out what it is and fix it.– Usually it means you have not automated your testing!– Not enough information early– Coding scheduled until the very last day of the sprint– Last-minute cuts that have to be handled in the doc
  • Planning the Release
  • © 2013 NetIQ Corporation. All rights reserved.10Release Planning• Release planning involves choosing a set of userstories that have been estimated, that match thePM/PO’s requested release theme, which we expectwe can fit into a timely release. All of this is based onthe scrum team’s expected velocity.• You should have at least enough sprint-able high-priority user stories broken down to fill the first sprint.• Ideally, you will have a rough idea of what stories youwill address in the first 2-3 sprints.• Resolve major dependencies and uncertainties inearly sprints. Then you can estimate a date range forshipping.
  • © 2013 NetIQ Corporation. All rights reserved.11Release Planning for Info Dev
  • © 2013 NetIQ Corporation. All rights reserved.12Review Cycles• Use two to three drafts: first draft, approval draft,quality edit draft (if needed).• Write doc for a feature in the sprint in which it isdeveloped and tested.• Have SMEs review the doc for technical accuracybefore closing the user story (“first draft”).• Eliminate the formal first draft for mature products.• Use the full approval draft to show context.
  • © 2013 NetIQ Corporation. All rights reserved.13Benefits of Adjusted Review Cycle• Info Dev gets more thorough reviews.• The documentation is more technically accurate andhigher quality.• The team member’s needed capacity for an approvaldraft is reduced.• Multiple approval drafts for multiple books on multipleproducts isn’t such a big hit all at once on the teammember’s time.
  • Creating User Stories
  • © 2013 NetIQ Corporation. All rights reserved.15What is a User Story?• Software requirement written from the user’s point ofview• Definition of what is to be built• Prioritized piece of the backlog• Often part of an “epic” or “theme”
  • © 2013 NetIQ Corporation. All rights reserved.16Making User Stories About the User• Problem statement (PS):• What behavior is functionally broken and how?• What is the user’s pain?• Must be user-facing.• Developer working the issue writes the initial statement.• Product architect, QE, and ID provide input. Everyone involved must approvebefore it’s included in the user story.• Acceptance criteria (AC):• How will users know the problem is fixed?• Before QE accepts a user story, it must meet the AC.• Developer working the issue writes the initial criteria.• Product architect, QE, and ID provide input. Everyone involved must approvebefore it’s included in the user story.• Acceptance tests (ATs):• What tests will QE run to determine whether the user story meets the AC?• Written by Dev and QE. Rarely require ID input.
  • © 2013 NetIQ Corporation. All rights reserved.17Example• Initial PS/AC:• PS:When user attempt to uninstall and reinstall the UNIX managed Agent without removing UNIX managedAgent from the AppManager, it actually revoking the AD-HOC maintenance mode flag (if already set) forUNIX managed Agent from console.• AC:AD-HOC maintenance mode flag for the UNIX managed Agent can be reset either by user from theconsole OR by cold start the UNIX managed Agent.• Architect/ID input:• Do customers know “AD-HOC” flag?• The acceptance criteria seems to describe the workaround. What is the expected behavior after the fix?• Final customer-facing PS/AC:• PS:If a UNIX computer is in maintenance mode and the user manually uninstalls and reinstalls the agent onthat computer but does not delete the agent from the Operator Console/Control Center console, whenthe reinstalled agent comes back online AppManager automatically removes it from maintenance mode.• AC:If a UNIX computer is in maintenance mode and the user manually uninstalls and reinstalls the agent onthat computer but does not delete the agent from the Operator Console/Control Center console, whenthe reinstalled agent comes back online AppManager does not automatically remove it frommaintenance mode.• Resulting Release Notes entry:If a UNIX computer is in maintenance mode and you uninstall and then reinstall the UNIX agent on thatcomputer but do not delete the agent from the Operator Console and Control Center console, AppManagerno longer removes the computer from maintenance mode when the reinstalled agent comes back online.
  • © 2013 NetIQ Corporation. All rights reserved.18Why Spend Time Writing Them?• For each user story, everyone knows:• What problem they’re fixing (PS)• Why they’re fixing it (PS)• What the expected behavior is once they fix the problem (AC)• How they’ll determine whether they fixed the problem (ATs)• The user stories clearly define the scope of the release.• Pre-defined ATs eliminate unnecessary ad-hoc testing.• Since everyone agrees on the PS/AC and they become the mainsource for writing the documentation, writing and getting approvalfor the doc should require less time.• They can expose possibilities for usability testing.
  • © 2013 NetIQ Corporation. All rights reserved.19Why Spend Time Writing Them?• They can bring to light issues that aren’t really issues or solutionsthat don’t provide the fix the user really needs:• If you can’t describe how the issue impacts the user, it’s probably notworth spending the time to fix.• If you can’t articulate the acceptance criteria in a way that shows theuser the problem is fixed, you probably haven’t identified the rootcause of the issue. If you know what the fix is, you should be able toexplain why it works from the user’s perspective.• They force everyone to think about the user impact.
  • © 2013 NetIQ Corporation. All rights reserved.20Why Spend Time Writing Them?• Ensures Development is providing a complete end-to-end solution of what is expected (and nothing more).• Ensures QE is testing what’s promised from a userperspective.• Ensures ID understands the feature in a way that theycan write documentation targeted to the user’s needsin this area.• Ensures the product owner is comfortable with theteam’s understanding of the requirements.
  • © 2013 NetIQ Corporation. All rights reserved.21Backlog Grooming• Planning poker– Discussion among team members, clarification from PO– Estimation using story points for all functional areas’completion– User stories that you will work on in the near future (the nextfew sprints) need to be small enough that they can becompleted in a single sprint.– User stories or other items that are likely to be more distantthan a few sprints can be left as epics or themes.– Team involvement from everyone• Prioritization – based on story ROI• Frequency
  • Sprint Planning
  • © 2013 NetIQ Corporation. All rights reserved.23Sprint Backlogs• Pull items from product backlog to sprint backlogduring team sprint planning.• Estimate your tasks using hours.• Ensure you include time for overhead items, such ascreating book structures, help structures, and virtualmachine setup.• Ensure your hours fit in to your capacity for thatproject that sprint.
  • © 2013 NetIQ Corporation. All rights reserved.24Determining Capacity• Consider previous sprint estimates.• Include vacation and non-sprint responsibilities.– Consider planning meetings, customer support, backloggrooming, demos, and retrospectives.– Estimate approximately 20% of each team member’s time forthese.• Do not include the first or last day of the sprint(depending on planning schedule).• Ensure Development finishes early so QE and ID cancomplete their tasks before the sprint ends.
  • © 2013 NetIQ Corporation. All rights reserved.25Determining Capacity• Meredith is a team member for Project A and Project B.• Sprint 1 for Project A is Feb. 7-20.• Sprint 3 for Project B is Feb. 5-18.• Project B has a planning day Feb. 15, so Meredith’s capacity for Feb. 15 onProject A is 0.
  • © 2013 NetIQ Corporation. All rights reserved.26Coping with Multiple Projects andMeetings• Work with your lead or manager to spread yourworkload so you can delegate standup meetingattendance to others.• Attend meetings that pertain to your highest priorityproject only.• Ask the scrum master to send status emails for themeetings so you know what you missed.• Ensure you have a presence on your team so yourteam doesn’t forget you when you’re not there.• Determine when the best time for team kickoffs areand get involved then.
  • © 2013 NetIQ Corporation. All rights reserved.27Sizing ID Work• Create more accurate estimates by applying astandard number of hours per page of documentationbased on the level of source material.• Plug in your tasks based on the information in the userstory to quickly estimate the amount of work needed tocomplete your tasks.• Compare the number of hours required to completetasks to total hours of team member capacity.• Ensure you include tasks for usability testing, UIreview, documentation improvements, bug fixing, etc.
  • © 2013 NetIQ Corporation. All rights reserved.28Sizing ID Work – Example
  • © 2013 NetIQ Corporation. All rights reserved.29“Potentially Shippable” Product• “Potentially Shippable” means for just the part of theproduct developed in that sprint.– The documentation for those user stories is complete and shippable.– The UI review for those user stories is complete and changesimplemented.– The entire book and help system probably are not complete andshippable until some ID-only user stories are complete in the lastsprint or even after sprints.– The concept(s), procedure(s), and reference(s) necessary for thatuser 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.
  • © 2013 NetIQ Corporation. All rights reserved.30ID-Driven User Stories and Tasks• These user stories and tasks happen during sprints.– Targeted doc improvement user stories and tasks– Can include tasks for subject matter expert review– Usability test user stories and tasks– Include tasks for Dev and QE to participate and then bugs ornew user stories to accommodate the results– UI review tasks– Tasks in existing user stories for features– Can include Dev and QE tasks to code and test changes
  • © 2013 NetIQ Corporation. All rights reserved.31ID-Only User Stories and Tasks• These user stories and tasks happen in last sprints orafter sprints.– Approval Draft of the whole document– Incorporation of Approval Draft comments– Final Review by ID lead (if needed)– Production Process– Finalize Release Notes
  • © 2013 NetIQ Corporation. All rights reserved.32References• Agile Testing: A Practical Guide for Testers and Agile Teams. LisaCrispin and Janet Gregory.• Agile Testing with Lisa Crispin Blog.http://lisacrispin.com/wordpress/2011/04/26/the-whole-team-approach-in-practice/• Product Owner Training for NetIQ. Kenny Rubin, Innolution.www.innolution.com• Rocket Surgery Made Easy – Steve Krug.• Mobile and Agile: The Floating Writer’s Survival Kit. 2008 STC Summitpresentation, Alyssa Fox and Meredith Kramer.• The Whole Team Approach. Internal NetIQ presentation, Ed Spire.• Delivering “On Time, As Promised, With Quality”. Internal NetIQpresentation, Angela Stagg.
  • © 2013 NetIQ Corporation. All rights reserved.33Thank you.Questions?
  • © 2013 NetIQ Corporation. All rights reserved.34+1 713.548.1700 (Worldwide)888.323.6768 (Toll-free)info@netiq.comNetIQ.comWorldwide Headquarters1233 West Loop SouthSuite 810Houston, TX 77027 USAhttp://community.netiq.com