The document provides information about an internship at APD including background on mentoring and networking opportunities. It then discusses project planning and defect management processes. Defects are prioritized based on severity and priority levels with examples provided. Meeting agendas and core sponsors are listed, with key takeaways focusing on career development and return on investment from the internship experience.

1. APD Intern
Presentation
JaTia Underwood

2. 1
Internship Background
MentorshipOpportunitiesNetworkingRelease ManagementYear Up

3. Project Plan

4. 3
Defect Management
P2
Severity
Priority
Low
Service
annoyance
and/or
obstacles to
usage
Medium
Service
availability
impacting ability
to work; system
performance
degraded <50%
High
Service
availability
impairing ability
to work; system
performance
degraded >50%
Urgent
Service unavailable;
service performance
severely degraded
Small
Single user / Customer
Large
Most customers /
users for service are
affected
Severe
All customers / users
for service are affected
P4 P4 P3 P2
Moderate
Some customers / user
for service are affected
P4 P3 P3 P2
P3
P3
P3
P2
P1
P1 P1
Term Defect Incident Example
Priority Is used to
determine the
order of
importance of
work
Is used to
determine the
order of
importance to
minimize
impact to
business
A critical priority
issue is a
customer’s
business name is
spelled incorrectly,
they’re upset, and
so you want to get
it fixed. It has low
severity because it
doesn’t affect the
system overall.
Severity Is used to
identify the
degree of impact
to the
development or
operation of a
component or
system
Is used to
identify the
degree of
impact to
business
A high severity
incident could be an
incident that affects
the operation of a
business
applications but
work can be
continued with
some restriction. It
has a high priority
(P2-P3) because it
doesn’t completely
affect work
availability.
Another example is
Autotrader.com
Homepage is down;
whereas a Low
Severity is one user
is experiencing slow
performance on
their machine.

5. 4
TOM

6. 5
2017 Agile Space Planning

7. 6
Agile Shadowing
Role Observation Comparison
Scrum Master
• Strong facilitation, ensuring
continuous progress in meetings.
• Ability to work with others to
achieve goals
• Promotion of self-management as
a leader/coach
• Self-motivated
• Planning/Organized
• Assertive in keeping people on task.
• Social-able Soft skills
• Supportive and encouraging
• team player, Leadership skills
• Takes initiative
• Self organized with planning skills
Kanban Lead
• a visualizer who creates and
manages the flow of the team
• a body guard against any risk
• a open communicator, who can
establish an environment
• Views things from a broad scope
with every angle
• Great interpretation in
communicating with people
QA Lead
• Focuses on the quality of products
delivered.
• Steadfast on the quality of work
produced.
• Visualizer in understanding what
background work needs to be done
for the perfect deliverable.
• Detail oriented
• Critical thinker
• Analytical

8. 7
Sponsor/Team
Sherolyn Sellers
Gary Reissner
Megan WilsonAmy Gregin
Kevin Long
Shawn
Stewart
Randy Baltus
Brad Hugick
Marla Tandy
Patryk
Symchych
Brent
Stevens
Rey Agyeman
Scott Elder
Being a
leader,
and
adapting
to change
Brian
Geesey
Secrets to
being a
scrum
master and
delegation
Eric Reese
Sharon JordanKristy Dye
Nancy Pietrosewicz
Cherie
Kirkland
Using your soft
skills to get
things
accomplished

9. 8
Core Sponsors
Sherolyn Gary Megan
• Space Planning
• Project Management
Leslie Knopes
• Defect Management
• Process Management
Dr. Spencer Reid
• Metrics Maturity
• Knowledge
Management
Felicity Smock

10. 9
Key Take A ways
• Strong sense of career path
• Valuable experience
• Return on Investment

11. 10
THANK YOU!

12. Appendix

13. 12
Tracking Defects
Sprint
(Lowest Priority)
Bugs found within
Sprint
Next Sprint,
Hardening,
Regression, Release
(Medium Priority)
“Escaped” out of Sprint
“Slipped” out of Sprint
Production
(Highest Priority)
“Escaped” into
production “Slipped” into
production
During a sprint when there is an
issue with a user story then it is fixed
through communication between
the dev and QA. We don't consider
those defects. Nothing is written up
for items fixed within the sprint.
If something can't be fixed within the
sprint then either the story stays open
and moves to the next sprint and
issues are written up in V1. Or a new
story is written.
A new story is only written if it is
decided that the issue does not fall
within the original story but it was
found during the dev or testing of the
story and is related
We don't call anything a defect or write
it up as such until the issue is in
production.
Session #1 Session #2
User Story 1
User Story 2
User Story 3
Regression Testing
on a merged
branch
Anything escaped from
here is considered
escaped into
production.
Defect is not found in
the work done here. It
is considered a sprint
escape.
2 week Sprint
User Story 4
Next Sprint
User Story 5
Defects escaped into
production, moves to another
user story, into the next sprint.