info dev flexibility in agile

Bending Without Breaking:Info Dev Flexibility in Agile

Alyssa FoxDirector, Information Development

[email protected]

713-418-5334

mailto:[email protected]

© 2013 NetIQ Corporation. All rights reserved.2

Making 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


The Scrum Team

• Product Owner

• Scrum Master

• Development Team– Dev

– QE

– ID


The Whole Team Approach

• The Old Way– Divisions among functional areas may mean that the whole

team 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”


The Whole Team Approach

• The New Way– The whole team understands exactly what we are (and are

not) building.

– The whole team accepts responsibility for completing ALL aspects of each user story (including quality and documentation tasks).

– The whole team acknowledges that the user story is not done until it is tested, all stop-ship bugs are fixed, and it is documented.

– Quality and documentation tasks occur within the same sprint as development tasks, not lagging behind.

– “Not Done” and “Done”


Ways 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 environments for others, writing first drafts of documentation, backlog grooming)

– Note that resource constraints might mean you work on another project once done in this project’s sprint.


Swarming

• Making QE and ID truly part of the Eng team means giving them the 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 occur during the sprint. Not just at the end of the sprint or in the next sprint.

• If you have a testing or doc crunch at the end of the sprint, you are 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


Release Planning

• Release planning involves choosing a set of user stories that have been estimated, that match the PM/PO’s requested release theme, which we expect we can fit into a timely release. All of this is based on the 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 you will address in the first 2-3 sprints.

• Resolve major dependencies and uncertainties in early sprints. Then you can estimate a date range for shipping.


Release Planning for Info Dev


Review 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 is developed and tested.

• Have SMEs review the doc for technical accuracy before closing the user story (“first draft”).

• Eliminate the formal first draft for mature products.

• Use the full approval draft to show context.


Benefits of Adjusted Review Cycle

• 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.

Creating User Stories


What is a User Story?

• Software requirement written from the user’s point of view

• Definition of what is to be built

• Prioritized piece of the backlog

• Often part of an “epic” or “theme”


Making 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 approve

before 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 approve

before 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.


Example• Initial PS/AC:

• PS:When user attempt to uninstall and reinstall the UNIX managed Agent without removing UNIX managed Agent from the AppManager, it actually revoking the AD-HOC maintenance mode flag (if already set) for UNIX managed Agent from console.

• AC:AD-HOC maintenance mode flag for the UNIX managed Agent can be reset either by user from the console 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 on that computer but does not delete the agent from the Operator Console/Control Center console, when the 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 on that computer but does not delete the agent from the Operator Console/Control Center console, when the reinstalled agent comes back online AppManager does not automatically remove it from maintenance mode.

• Resulting Release Notes entry:If a UNIX computer is in maintenance mode and you uninstall and then reinstall the UNIX agent on that computer but do not delete the agent from the Operator Console and Control Center console, AppManager no longer removes the computer from maintenance mode when the reinstalled agent comes back online.


Why 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 main source for writing the documentation, writing and getting approval for the doc should require less time.

• They can expose possibilities for usability testing.



• They can bring to light issues that aren’t really issues or solutions that don’t provide the fix the user really needs:

• If you can’t describe how the issue impacts the user, it’s probably not worth spending the time to fix.

• If you can’t articulate the acceptance criteria in a way that shows the user the problem is fixed, you probably haven’t identified the root cause of the issue. If you know what the fix is, you should be able to explain why it works from the user’s perspective.

• They force everyone to think about the user impact.



• 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 user perspective.

• Ensures ID understands the feature in a way that they can write documentation targeted to the user’s needs in this area.

• Ensures the product owner is comfortable with the team’s understanding of the requirements.


Backlog 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 next few sprints) need to be small enough that they can be completed in a single sprint.

– User stories or other items that are likely to be more distant than a few sprints can be left as epics or themes.

– Team involvement from everyone

• Prioritization – based on story ROI

• Frequency

Sprint Planning


Sprint Backlogs

• Pull items from product backlog to sprint backlog during team sprint planning.

• Estimate your tasks using hours.

• Ensure you include time for overhead items, such as creating book structures, help structures, and virtual machine setup.

• Ensure your hours fit in to your capacity for that project that sprint.


Determining Capacity

• 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.

• Do not include the first or last day of the sprint (depending on planning schedule).

• Ensure Development finishes early so QE and ID can complete their tasks before the sprint ends.


Determining 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 on

Project A is 0.


Coping with Multiple Projects and Meetings

• 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.


Sizing ID Work

• Create more accurate estimates by applying a standard number of hours per page of documentation based on the level of source material.

• Plug in your tasks based on the information in the user story to quickly estimate the amount of work needed to complete your tasks.

• Compare the number of hours required to complete tasks to total hours of team member capacity.

• Ensure you include tasks for usability testing, UI review, documentation improvements, bug fixing, etc.


Sizing ID Work – Example


“Potentially Shippable” Product

• “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.


ID-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 or new 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


ID-Only User Stories and Tasks

• These user stories and tasks happen in last sprints or after sprints.

– Approval Draft of the whole document

– Incorporation of Approval Draft comments

– Final Review by ID lead (if needed)

– Production Process

– Finalize Release Notes


References

• Agile Testing: A Practical Guide for Testers and Agile Teams. Lisa Crispin 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 Summit presentation, Alyssa Fox and Meredith Kramer.

• The Whole Team Approach. Internal NetIQ presentation, Ed Spire.

• Delivering “On Time, As Promised, With Quality”. Internal NetIQ presentation, Angela Stagg.

http://lisacrispin.com/wordpress/2011/04/26/the-whole-team-approach-in-practice/




http://www.innolution.com/


Thank you.

Questions?


+1 713.548.1700 (Worldwide)888.323.6768 (Toll-free)[email protected]

Worldwide Headquarters1233 West Loop South Suite 810 Houston, TX 77027 USA

http://community.netiq.com

mailto:[email protected]

http://www.netiq.com/

http://community.netiq.com/

http://www.facebook.com/netiq

http://www.twitter.com/netiq

http://www.linkedin.com/groups?gid=2745833

http://community.netiq.com/

info dev flexibility in agile

Technology