Info dev flexibility in agile

Bending Without Breaking:
Info Dev Flexibility in Agile
Alyssa Fox
Director, Information Development
alyssa.fox@netiq.com
713-418-5334

© 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

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.

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

Thank you.
Questions?

+1 713.548.1700 (Worldwide)
888.323.6768 (Toll-free)
info@netiq.com
NetIQ.com
Worldwide Headquarters
1233 West Loop South
Suite 810
Houston, TX 77027 USA
http://community.netiq.com

Info dev flexibility in agile

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie Info dev flexibility in agile

Ähnlich wie Info dev flexibility in agile (20)

Mehr von Alyssa Fox

Mehr von Alyssa Fox (10)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Info dev flexibility in agile