Learn how to create a product management process that works effectively for your organization. Slides taken from a class that Cory von Wallenstein of Dyn taught at Intelligent.ly. Learn more from the experts by visiting http://intelligent.ly/learn

1. presents
CORY VON WALLENSTEIN
Chief Technology Officer, Dyn Inc.
@cvonwallenstein
Tools of the Trade:
Creating a Product
Process that Doesn’t Suck

2. “Truly
Superior,
Differen1ated”
Products
had
an
average
98%
success
rate
and
53.5%
market
share.
“Me-­‐Too”
Products
averaged
an
18.4%
success
rate
and
11.6%
market
share.
Product
Leadership:
Crea2ng
and
Launching
Superior
New
Products
–
Robert
G.
Cooper
Photo
Credit:
h2p://www.flickr.com/photos/idletype/526824467/

3. Agenda
1. Product
Litmus
Test
–
Is
this
working?
2. Product
vs
Project
Management
–
Role
in
org
3. Deep
dive!
1. Product
management
top
to
boFom
2. Teams
driving
toward
success
3. Keeping
the
company
in
the
loop

4. But
First,
Who
Is
Dyn?
• 170
Global
Employees
• Headquarters
in
Manchester,
NH
• Offices
in
San
Francisco
and
Brighton,
UK
• Raised
first
financing
in
Oct
2012:
$38MM
from
NorthBridge

5. Product
Litmus
Test
Is
this
working?

6. hZp://www.flickr.com/photos/alshepmcr/4859805312/

7. Is
what
we’re
doing
now
working?
• Is
there
a
palpable
divide?
– When
will
X
be
done?
– What’s
blocking
X?
• Is
it
a
bug
or
a
firewall
config
or
logo
or
contract?
– When
can
we
start
Y?
– What’s
the
priority
in
the
grand
scheme
of
things?
– Is
Kari
available
to
help
with
something
next
week?
– When
can
we
safely
switch
gears?
– What
defines
80%
complete?

8. Manifesto
for
Agile
So<ware
Individuals
and
interac1ons
over
processes
and
tools
Working
so<ware
over
comprehensive
documentaJon
Customer
collabora1on
over
contract
negoJaJon
Responding
to
change
over
following
a
plan
That
is,
while
there
is
value
in
the
items
on
the
right,
we
value
the
items
on
the
le<
more.
hZp://agilemanifesto.org

9. Product
vs
Project
Management
What
is
the
role
of
Product
Management
in
the
org?

10. What
is
Product
Management?
• Read
a
great
overview
presentaJon

11. What
is
Product
Management?
• At
Dyn
Inc.,
largely
concerned
with
what
features
and
improvements
go
into
the
products
in
what
order.
• Ideas
for
features
and
improvements
come
from
everywhere
– Prospects,
customers,
internal
teams,
etc.
• Collaboradve
process
with
execs
and
directors
to
set
priorides
for
what
to
take
on,
and
when
• Funcdonal
specificadons
for
what
is
to
be
built

12. What
is
Project
Management?
• At
Dyn
Inc.,
largely
concerned
with
coordinaJon
of
resources
to
efficiently
execute
on
the
plans
set
forth
by
product
management.
• CollaboraJve
process
between
directors
and
managers
to
set
schedules,
remove
roadblocks
and
communicate
progress.
• Most
important:
Deliver
value
constantly.

13. Few
Quick
DefiniJons
• Sprint
– Easy
definiJon:
Up
to
two
weeks
of
work.
You’ll
hear
it
used
as
“current
sprint”
and
“next
sprint”.
– Complete
definiJon:
One
or
two
weeks
on
the
calendar
(defined
by
directors/managers),
such
that
all
work
assigned
to
the
sprint
will
be
complete
by
the
end
of
the
sprint.
Well
defined
points
to
flexibly
change
focus
before
or
a`er
a
sprint.

14. Few
Quick
DefiniJons
• Story:
A
business
focused
descripJon
of
new
or
changed
funcJonality
that
can
be
done
in
one
sprint.
To
be
divided
into
technical
and
business
tasks.
hZp://www.slideshare.net/rwirdemann/user-­‐stories-­‐for-­‐your-­‐product-­‐backlog

15. Few
Quick
DefiniJons
• Epic:
A
collecJon
of
stories
that
span
sprints.
• Technical
task:
Technical
work
required
to
bring
a
story
to
fruiJon.
Design
architecture,
write
code,
create
mockup,
code
review,
etc.
• Business
task:
Non-­‐technical
work
required
to
bring
a
story
to
fruiJon.
Define
objecJves/
goals/measurables,
write
specificaJon,
create
graphics
and
content,
blog
entries,
etc.

16. Few
Quick
DefiniJons
• Bug:
Broken
funcJonality
that
needs
to
be
corrected.
Bugs
do
not
describe
new
funcJonality,
only
exisJng
funcJonality
that
no
longer
works.
• Feature
Request:
New
funcJonality.
• Improvement
Request:
ExisJng
funcJonality
that
works
as
designed,
but
could
work
beFer.

17. Deep
Dive!
Let’s
see
this
process
and
tools
in
acJon!

18. How
does
it
come
together?
Feature
Requests
• From
prospects,
customers,
internal
teams,
etc.,
all
the
ideas
we
may
do,
sorted
by
priority
• We
track
who
asks
for
what,
and
how
frequently
• Execs,
VPs
&
directors
keep
three
sorted
priority
lists
by
category:
DNS,
Email
&
Internal
• We
conGnuously
add
new
requests,
and
we
review
prioriGes
minimum
of
2x
per
week.
Product
Backlog
• Feature
requests
are
work
we
may
do;
the
product
backlog
is
work
we
will
do,
sorted
by
priority.
• The
top
priority
requests
get
evaluated
in
detail,
with
a
target
pace
of
1-­‐2
per
week
• VPs
use
a
product
lifecycle
process
to
figure
out
what’s
needed
to
implement
the
request,
directors
write
specificaGons
(e.g.,
epics
and
stories),
and
get
ready
for
teams
to
execute.
Sprints
and
Releases
• Directors
and
managers
define
the
work
described
by
stories
into
actual
tasks,
and
schedule
efforts.
• Managers
work
in
two
week
sprints,
each
culminaGng
in
at
least
some
value
delivered
to
someone.
• On
release
of
large
efforts
(e.g.,
epics),
VPs
&
directors
coordinate
the
launch
using
a
product
lifecycle
process
again.

19. Feature
Requests
• From
prospects,
customers,
internal
teams,
etc.,
all
the
ideas
we
may
do,
sorted
by
priority
Product
Backlog
• Feature
requests
are
work
we
may
do;
the
product
backlog
is
work
we
will
do,
sorted
by
priority.
Sprints
and
Releases
• Directors
and
managers
define
the
work
described
by
stories
into
actual
tasks,
and
schedule
efforts.
• What
Does
Product
Planning
Mean?
1.
Get
the
ideas

20. Feature
Requests
• From
prospects,
customers,
internal
teams,
etc.,
all
the
ideas
we
may
do,
sorted
by
priority
Product
Backlog
• Feature
requests
are
work
we
may
do;
the
product
backlog
is
work
we
will
do,
sorted
by
priority.
Sprints
and
Releases
• Directors
and
managers
define
the
work
described
by
stories
into
actual
tasks,
and
schedule
efforts.
• What
Does
Product
Planning
Mean?
Kicka
1.
Get
the
ideas
2.
Priori0ze
the
ideas,
driven
by
opportunity,
pain,
number
of
customers.

21. Feature
Requests
• From
prospects,
customers,
internal
teams,
etc.,
all
the
ideas
we
may
do,
sorted
by
priority
Product
Backlog
• Feature
requests
are
work
we
may
do;
the
product
backlog
is
work
we
will
do,
sorted
by
priority.
Sprints
and
Releases
• Directors
and
managers
define
the
work
described
by
stories
into
actual
tasks,
and
schedule
efforts.
• What
Does
Product
Planning
Mean?
Kicka
1.
Get
the
ideas
2.
Priori0ze
the
ideas,
driven
by
opportunity,
pain,
number
of
customers.
3.
At
a
high
level,
what
needs
to
be
done?
That’s
the
func0onal
specifica0on.

22. Feature
Requests
• From
prospects,
customers,
internal
teams,
etc.,
all
the
ideas
we
may
do,
sorted
by
priority
Product
Backlog
• Feature
requests
are
work
we
may
do;
the
product
backlog
is
work
we
will
do,
sorted
by
priority.
Sprints
and
Releases
• Directors
and
managers
define
the
work
described
by
stories
into
actual
tasks,
and
schedule
efforts.
• What
Does
Product
Planning
Mean?
Kicka
1.
Get
the
ideas
2.
Priori0ze
the
ideas,
driven
by
opportunity,
pain,
number
of
customers.
3.
At
a
high
level,
what
needs
to
be
done?
That’s
the
func0onal
specifica0on.
4.
What
are
the
tasks
that
bring
this
idea
to
life?
Where
do
they
fit
in
the
schedule?
What
non-­‐technical
tasks
are
required
to
make
it
successful?

23. What
Does
Product
Planning
Mean?
1. Get
the
ideas
2. PrioriJze
the
ideas
3. Specify
the
funcJonality
for
the
idea
4. IdenJfy
the
tasks
required
to
bring
the
idea
to
life,
and
schedule
the
tasks
for
teams
to
work
on.

24. 1.
Get
the
Ideas
• Primarily
in
the
form
of
feature
requests
and
improvement
requests
that
come
from
the
dashboard
• Click
“Feature
Request”
or
“Improvement
Request”
for
DNS,
Email
or
Internal.

25. Examples
of
Feature
Requests
Customer
Idea
for
New
Funcdonality
• Example
request:

26. Examples
of
Feature
Requests
Customer
Idea
for
Improvement
• Example
request:

27. Examples
of
Other
Feature
Requests
• Could
be
an
improvement
to
a
UI
or
workflow
– Include
screenshots
that
show
where
the
confusion
or
pain
is,
or
under
what
circumstances
the
pain
is
introduced
• Could
be
a
change
to
how
a
service
works
– For
example,
on
failover
of
a
hostname,
provide
just
the
failover
IP
for
the
purpose
of
secondary
DNS
providers
to
consume.
• Could
be
an
internal
improvement
request
– For
example,
connect
our
Salesforce.com
account
to
other
systems
– Speed
up
a
tool
that
is
slow

28. 2.
PrioriJze
the
Ideas
• ConJnue
to
add
addiJonal
support
for
ideas
as
new
customers
request
the
same
features
or
improvements
• Comment
on
ideas
to
add
support
• Vote
on
ideas
• Directors
and
execuJves:
Adjust
the
prioriJes
of
the
ideas

29. Add
addiJonal
support
• Has
another
customer
requested
a
feature
that
we’re
already
tracking?
Add
them!
• Add
another
row
to
the
table
in
the
descripJon

30. Comment
on
ideas
• Add
your
insights,
addiJonal
customers
to
look
at,
and
other
ideas
that
can
help
decide
where
this
should
sit
in
the
priority
stack.

31. Vote
on
ideas
• VoJng
is
another
way
to
register
your
support,
parJcularly
for
internal
feature
and
improvements
that
make
our
lives
easier.

32. PrioriJzaJon
in
AcJon
• VPs,
execs
&
directors
review
and
adjust
prioriJes
3x
per
week.
• Be
sure
to
leave
a
comment
as
to
WHY
you
changed
the
priority!
• Priority
adjustments
appear
in
the
history
of
the
issue
for
who
changed
what
and
when,
and
will
alert
via
an
email
noJficaJon
to
watchers.

33. PrioriJzaJon
in
AcJon
Changing
rank
logs
the
change
and
sends
a
no0fica0on
Be
sure
to
comment
WHY
you
made
the
change,
especially
if
bumping
to
at
or
near
the
top.

34. Feature
Requests
• From
prospects,
customers,
internal
teams,
etc.,
all
the
ideas
we
may
do,
sorted
by
priority
Product
Backlog
• Feature
requests
are
work
we
may
do;
the
product
backlog
is
work
we
will
do,
sorted
by
priority.
Sprints
and
Releases
• Directors
and
managers
define
the
work
described
by
stories
into
actual
tasks,
and
schedule
efforts.
• Requests
in
a
Queue
vs
Stories
in
a
Backlog
Kicka
The
JIRA
issue
types
of
“Feature
Request”
and
“Improvement
Request”
represent
the
never
ending
“wishlist”.
Ideally
it’s
a
mess,
because
it’s
everything,
and
we
have
yet
to
sort
through
which
requests
we’re
taking
on
and
which
we
are
not.
The
JIRA
issue
types
of
“Story”,
“Bug”,
“Epic”
and
the
sub-­‐tasks
represent
work
we
have
definitely
agreed
to
take
on,
scope
out,
and
deliver.
It’s
just
a
maer
of
scheduling.
This
is
the
backlog!
It’s
ideally
clean,
because
it’s
stuff
we
have
agreed
to
take
on.
The
“Request”
issues
link
to
the
associated
backlog
issues
in
JIRA.

35. 3.
FuncJonal
specificaJons
4.
IdenJfy
tasks,
assign
&
schedule
• We’ll
cover
these
in
detail
in
the
final
secJon
of
the
training
on
“Teams
driving
toward
success”
and
day-­‐to-­‐day
JIRA
usage.

36. Teams
Driving
Toward
Success
• WriJng
really
useful:
– Bug
reports,
stories
and
epics
– Technical
and
business
subtasks
– FuncJonal
and
technical
specificaJons
• Workflows
for
issues
and
transiJons
• Scheduling
sprints,
due
dates
and
releases
• Keeping
your
plans
accurate
to
reality
• CreaJng
and
using
dashboards
to
stay
in
the
loop

37. WriJng
Useful
Bug
Reports
• Bug:
Broken
funcJonality
that
needs
to
be
corrected.
Bugs
do
not
describe
new
funcJonality,
only
exisJng
funcJonality
that
no
longer
works.

38. WriJng
Useful
Bug
Reports
• Use
the
summary
to
describe
what
is
broken
and
the
impact
in
plain
English.
• Good
examples:
– Users
from
Canada
cannot
checkout
their
cart
because
they
are
marked
as
fraudulent
purchases.
– Zone
changes
larger
than
50
resource
records
in
size
fail
to
publish.
– Leaving
TTL
text
field
blank
throws
HTTP
500
to
user.

39. WriJng
Useful
Bug
Reports
• Use
the
summary
to
describe
what
is
broken
and
the
impact
in
plain
English.
• Bad
examples:
– Checkout
error
– Line
50
of
checkZone.pl
is
wrong
– Internal
Server
Error
500

40. WriJng
Useful
Bug
Reports
• In
the
descripJon,
include
steps
necessary
to
reproduce
the
bug.
• AFach
a
screenshot
or
otherwise
capture
the
“evidence”
that
the
bug
exists,
and
place
in
the
descripJon.

41. Few
Quick
DefiniJons
• Story:
A
business
focused
descripJon
of
new
or
changed
funcJonality
that
can
be
done
in
one
sprint.
To
be
divided
into
technical
and
business
tasks.

42. WriJng
Useful
Stories
• Why
bother
with
the
whole
story
thing?
– Convey
what’s
going
on
in
terms
anyone
can
understand.
– Force
us
to
think
about
taking
on
work
in
small
chunks,
so
we
can
conJnuously
deliver
value
and
be
nimble
to
changing
course
if
necessary.
Stories
cannot
span
sprints.
– Define
what
value
is
geong
delivered
for
whom
to
set
clear
expectaJons
on
what
“done”
means.

43. WriJng
Useful
Stories
• Think
about
the
end
result
you’re
trying
to
achieve,
and
try
to
aFack
it
in
ways
that
will
ensure
you’re
delivering
some
value
to
some
user
at
least
every
sprint,
even
if
that
user
is
yourself
as
a
developer.
• Follow
the
template:
– As
a
[user
role],
I
want
some
[goal]
so
that
[reason].

44. WriJng
Useful
Stories
• As
large
efforts
progress,
you’ll
start
to
see
the
value
shi`
from
internal
to
external
user
roles.
– First
sprint:
As
a
developer…;
As
a
tester…;
– Second
sprint:
As
a
system
administrator…;
– Third
sprint:
As
an
internal
alpha
user…;
– Fourth
sprint:
As
a
closed
beta
user…;
– Fi`h
sprint:
As
a
customer…;
– Sixth
sprint:
As
a
customer…;
– Seventh
sprint:
As
a
customer…;

45. WriJng
Useful
Stories
• If
the
story
implements
a
Feature
Request
or
Improvement
Request,
link
it!
• More
Acdons
-­‐>
Link,
then
search
for
the
issue
• Use
“implements”
going
from
Story
to
Feature/Improvement
request.
Automadcally
creates
reverse
link
of
“is
implemented
by”.

46. WriJng
Useful
Stories
• The
descripJon
of
the
story
contains
any
necessary
implementaJon
details
and
technical
specificaJon,
like
mockups,
architecture
diagrams,
state
diagrams,
etc.
• Include
pictures,
create
Gliffy
diagrams,
link
to
documents
in
Confluence.
• We’ll
explore
breaking
the
story
down
into
tasks
a`er
we
look
at
epics
real
quick…

47. WriJng
Useful
Epics
• Epic:
A
collecJon
of
stories
that
span
sprints.
• Only
needed
if
it
truly
spans
sprints.

48. WriJng
Useful
Epics
• Summary
describes
the
effort
– High
availability
for
portal
and
API
– Geo
Traffic
Management
• DescripJon
contains
the
project-­‐wide
technical
specificaJon
– Remember,
the
funcJonal
specificaJon
is
tracked
on
the
Feature
Request
or
Improvement
Request.
– Large
efforts
have
tech
specs
on
epics;
small,
less
than
two
week
efforts
have
tech
specs
on
story

49. WriJng
Useful
Epics
• On
your
stories,
be
sure
to
set
the
Epic.
It
has
to
be
explicitly
set
on
each
Story.
Can
be
bulk
changed.

50. WriJng
Useful
Sub-­‐tasks
• Sub-­‐tasks
are
where
we
define
the
actual
work
that
needs
to
be
done,
by
whom,
and
by
when.
• Free
to
use
summary
and
descripJon
as
necessary
to
convey
task
requirements.
• OK
to
group
smaller
tasks
in
the
descripJon
of
a
sub-­‐
task
as
a
bulleted
or
numeric
list
(e.g.,
ten
things
that
each
take
5
minutes…)
• Technical
(write
code,
install
package)
and
business
(create
logo,
sign
contract)
sub-­‐task
types.

51. WriJng
Useful
Sub-­‐tasks
• Most
important:
TIME
ESTIMATES!
• Used
for
the
burndown
charts,
that
convey
to
the
rest
of
Dyn
Inc.
when
an
effort
is
expected
to
be
completed.

52. WriJng
Useful
Technical
Sub-­‐tasks

53. WriJng
Useful
Business
Sub-­‐tasks
• Logos,
contracts,
feedback,
approvals,
etc.

54. WriJng
Useful
FuncJonal
Specs
• What
does
the
implemented
idea
look
like?
What
are
the
requirements?
How
do
you
define
it’s
done
and
it’s
successful?
• Describe
with
user
stories,
workflow
diagrams,
and
interface
mockups
• Leave
no
quesJon
unanswerable.

55. WriJng
Useful
Technical
Specs
• How
are
we
going
to
implement
the
funcJonal
specificaJons?
• System
architecture,
state
diagrams,
pseudo-­‐
code
as
needed
to
convey
how
to
implement.
• If
the
funcJonal
specificaJons
live
on
(or
are
linked
from)
the
Feature
or
Improvement
request,
the
technical
specificaJons
live
on
(or
are
linked
from)
the
highest
level
Epic
or
Story
for
the
effort.

56. Workflows
for
Issues
• Open
or
Re-­‐opened
-­‐>
In
Progress
-­‐>
In
QA
-­‐>
Closed
• What
does
Open
mean?
– Queued
up
for
an
individual
to
work
on
according
to
priority
stack.
• What
does
Re-­‐opened
mean?
– It
previously
went
through
at
least
up
to
In
QA
or
Closed,
and
needs
more
aFenJon
that’s
not
being
given
right
this
moment
(otherwise,
would
have
gone
back
to
In
Progress).

57. Workflows
for
Issues
• Open
or
Re-­‐opened
-­‐>
In
Progress
-­‐>
In
QA
-­‐>
Closed
• What
does
In
Progress
mean?
– You’re
working
on
it
today.
OK
to
have
more
than
one
In
Progress
if
you’re
working
on
more
than
one
thing
in
a
day.
Not
OK
to
leave
it
In
Progress
if
you’re
not
working
on
it
today.
• What
does
In
QA
mean?
– Ready
for
peer
review.
TransiJon
to
In
QA
and
assign
to
a
peer
who
will
review
the
funcJonality.
EVERY
issue
gets
peer
reviewed.

58. Workflows
for
Issues
• Open
or
Re-­‐opened
-­‐>
In
Progress
-­‐>
In
QA
-­‐>
Closed
• What
does
Closed
mean?
– If
In
QA
failed
(e.g.,
more
work
or
changes
required),
goes
back
to
original
assignee
and
either
Re-­‐opened
to
work
on
later
or
In
Progress
if
they’re
going
to
jump
on
it
now.
– If
it
passes
peer
review,
can
be
Closed,
which
signals
that
it’s
ready
for
the
next
release.

59. Scheduling
Sprints,
Due
Dates
and
Releases
• Really
only
two
contexts
to
use
the
term
“sprint”:
– The
current
sprint:
Defined
value
that
the
teams
are
commiFed
to
delivering
in
two
weeks
or
less
on
the
calendar.
Working
on
it
now.
– The
next
sprint:
Defined
value
that
the
teams
are
commiFed
to
delivering
in
two
weeks
or
less
on
the
calendar…
as
soon
as
the
current
sprint
is
delivered.
• Anything
beyond
“the
next
sprint”
is
prioriJzed
in
the
backlog.
That’s
it.

60. Scheduling
Sprints,
Due
Dates
and
Releases
• OK,
we
have
our
sprint
scheduled,
what
about
release?
– A
version
in
JIRA
is
a
release
to
producJon.
When
you
know
you’re
going
to
take
advantage
of
a
code
release
day
to
release
code,
create
the
appropriate
version
in
your
project
with
the
“release
date”
set
to
your
release
day.
– Set
the
“fixversion”
on
your
issues
to
indicate
what
will
go
live
in
the
version.
These
will
later
become
your
release
notes.

61. Scheduling
Sprints,
Due
Dates
and
Releases
• We
missed
the
due
date!
We’re
late!
OH
NOZ!
– Not
to
worry,
these
things
will
happen.
– What’s
important
is
to
communicate
to
the
team:
1. That
it
happened.
Don’t
sweep
it
under
the
rug.
2. Why
it
happened,
so
you
can
think
about
what
to
keep
in
mind
for
next
Jme.
3. What
the
new
plan
is…
adjust
your
fix
versions,
due
dates,
and
other
planning
as
needed.
Comment
on
the
issues!
• There
are
lots
of
perfectly
valid
reasons
why
plans
may
change,
but
there
is
no
excuse
for
ignoring
the
change.

62. Keeping
your
plans
accurate
to
reality
• Here
we’ll
cover:
– Due
date
maintenance,
or
“we’re
clearly
not
going
to
get
all
of
this
done
for
release
day”
– Burndown
charts,
or
“when
is
project
X
going
to
be
done?”
– Time
tracking
with
SVN,
or
“keeping
our
burndown
charts
up
to
date
with
minimum
effort”

63. Due
Date
Maintenance
• When
changing
dates
on
a
fixversion,
all
issues
assigned
to
that
fix
version
must
be
changed
as
well
– Create
issue
filter
with
fixversion
of
‘x.x.x’
– Apply
bulk
change
to
all
issues
matching
filter
– Leave
comment
as
to
why
change
was
required

64. Due
Date
Maintenance
• When
changing
dates
on
a
fixversion,
all
issues
assigned
to
that
fix
version
must
be
changed
as
well
– Create
issue
filter
with
fixversion
of
‘x.x.x’
– Apply
bulk
change
to
all
issues
matching
filter
– Leave
comment
as
to
why
change
was
required

65. Burndown
Charts
• Burndown
charts
require
start
and
end
date
be
set
in
Chart
tool
– Create
a
filter
based
on
FixVersion
– Add
Burndown
chart
to
dashboard
– Set
start
and
end
date
on
info
tab

66. Burndown
Charts
• Burndown
charts
require
start
and
end
date
be
set
in
Chart
tool
– Create
a
filter
based
on
FixVersion
– Add
Burndown
chart
to
dashboard
– Set
start
and
end
date
on
info
tab

67. Time
Tracking
with
SVN
• Use
the
#
when
checking
in
to
record
Jme
and
comments
svn
commit
-­‐m
"ECTE-­‐862
Created
basic
interac0on
#0me
2h”8asic
in
#resolve
and
#close
work
too

68. Puong
It
All
Together
A
Dashboard
in
Confluence
that
the
whole
company
can
read.

69. Kickass
Products
at
Dyn
Inc!
Feature
Requests
Product
Backlog
3-­‐5
High
Profile
Projects
at
Dyn
Sprints
and
Releases
Each
pordon
of
the
process
has
a
corresponding
pordon
of
the
dashboard:
1. The
high
profile
projects
are
at
top
for
easy
reference
• This
is
what
most
folks
will
be
interested
in…
when
is
X
going
to
be
done?
• Not
part
of
the
“flow”,
just
a
handy
reference
secdon.
2. Feature
requests
for
DNS,
Email
and
Internal
in
sorted
priority.
3. Next
is
the
product
backlog
in
sorted
priority
by
team.
4. Followed
by
the
current
sprint,
with
work
grouped
by
team.

70. High
Profile
Projects
Let’s
look
at
the
first
secJon
in
detail:
the
High
Profile
Projects.
The
goal
of
this
secdon
is
give
you
a
quick
pulse
on
the
top
3-­‐5
efforts
at
Dyn
that
everyone
cares
about.
You’ll
see
whether
or
not
the
effort
is
acdvely
being
worked
on,
and
when
it’s
expected
to
be
complete.
Have
it
open?
Good!

71. High
Profile
Projects
• Three
porJons
to
pay
aFenJon
to:
– Switching
between
the
3-­‐5
high
profile
projects
– The
project
card,
which
gives
an
overview
of
the
effort,
and
links
to
the
associated
informaJon
in
JIRA
if
you’d
like
to
dive
into
the
details.
– The
burndown
chart,
which
plots
calendar
days
on
the
X-­‐axis
and
hours
remaining
on
the
Y-­‐axis.
When
hours
remaining
reaches
zero,
the
project
is
complete!

72. High
Profile
Projects
Switch
between
projects
by
clicking
the
tabs.
What
projects
are
shown
are
determined
by
CvW,
so
send
a
request
if
what
you
seek
isn’t
shown.

73. High
Profile
Projects
The
card
view
shows
the
parent
issue
in
JIRA
(likely
a
Story
or
Epic,
here
it’s
a
Story),
with
a
summary
of
the
effort,
what
version
it
will
release
in,
and
the
assignee
who
is
the
person
that
is
most
familiar
with
the
effort.

74. High
Profile
Projects
The
burndown
chart
shows
you
in
real-­‐0me
when
this
project
is
likely
to
complete.
The
red
line
is
a
guideline
predic0ng
comple0on,
and
the
green
line
is
work
remaining.
When
work
remaining
reaches
0,
the
project
is
done.
Read
more
about
burndown
charts.

75. Feature
Requests
Let’s
look
at
the
second
secJon
in
detail:
Feature
Requests.
The
goal
of
this
secdon
is
show
the
ideas
we
may
want
to
work
on,
in
sorted
priority.
Each
week,
teams
take
the
top
1-­‐2
feature
requests
and
spend
dme
figuring
out
what
it
would
take
to
implement
them
in
the
form
of
a
funcdonal
specificadon.
This
specificadon
gets
translated
into
stories,
which
will
appear
in
the
backlog.
Have
it
open?
Good!

76. Feature
Requests
• Few
porJons
to
pay
aFenJon
to:
– Categories
of
requests:
DNS,
Email
and
Internal
– InterpreJng
the
status
of
a
request
– Sorted
prioriJes,
and
how
to
change
them
– Going
beyond
the
top
10
prioriJes
– Diving
in
to
a
feature
requests
– CreaJng
new
feature
requests
vs
improvement
requests

77. Feature
Requests
Three
sec0ons,
lea
to
right:
DNS,
Email
and
Internal.
DNS
includes
all
DNS
products
and
services,
Email
includes
all
Email
products
and
services,
Internal
includes
everything
we
rely
on
internally
(Salesforce,
Phones,
Zimbra,
RT,
Billing
Portals,
etc.).

78. Feature
Requests
Let’s
zoom
in
on
DNS.
Everything
we
look
at
from
here
on
is
equally
applicable
to
DNS,
Email
and
Internal,
we’re
just
using
DNS
as
an
example.

79. Feature
Requests
Four
pieces
of
informa0on
are
shown.
The
first
is
implicit,
and
it’s
the
priority
of
the
request
gauged
by
the
posi0on
in
the
list
(top
issue
is
the
top
priority).
The
second
through
fourth
are
in
columns:
“Component”
is
the
product
or
service
(e.g.,
DynECT
Managed
DNS,
Dyn
Standard
DNS),
“Summary”
is
the
idea,
and
“Status”
is…
status.

80. Feature
Requests
If
the
status
is
“Open”,
it
means
no
one
is
looking
at
the
feature
request
at
the
moment.
If
the
status
is
“In
Progress”,
it’s
likely
in
ac0ve
implementa0on
by
teams.
If
it’s
anything
else
(e.g.,
Sales
Review,
Legal
Review,
etc.),
the
request
is
running
through
the
“Product
Lifecycle
Process”
used
by
the
director
team
to
evaluate
and
spec
out
requests.

81. Feature
Requests
“In
Progress”
requests
generally
have
their
work
defined
already
in
the
form
of
a
func0onal
specifica0on
and
stories
on
the
current
sprint
or
the
product
backlog.
Each
team
has
a
prac0cal
limit
for
the
number
of
requests
“In
Progress”;
as
each
effort
wraps
up,
the
next
highest
priority
request
is
taken
on.

82. Feature
Requests
Three
0mes
a
week,
directors
and
execu0ves
review
and
adjust
the
priori0es
of
requests
using
the
“Priori0ze”
link.
We’ll
discuss
priori0za0on
later
on,
but
for
the
moment,
it’s
worth
no0ng
that
unless
you’re
in
a
priori0za0on
mee0ng,
you
shouldn’t
change
anything
here.

83. Feature
Requests
Only
the
top
10
priority
feature
requests
are
shown
on
each
gadget.
To
see
lower
priority
requests,
click
the
link
at
the
bojom
that
says
“N
matching
issues”.
This
will
take
you
into
JIRA,
where
you
can
explore
all
feature
requests.

84. Feature
Requests
Clicking
a
summary
will
take
you
to
the
feature
request
in
JIRA,
where
you
can
comment
on
the
request,
watch
the
request
to
be
emailed
about
changes,
vote
on
the
issue
and
more.

85. Feature
Requests
Want
to
request
an
improvement
to
something
we
already
have?
Click
“Improvement
Request”.
Want
to
request
new
func0onality
that
we
do
not
already
have?
That’s
a
“Feature
Request”,
so
click
“Feature
Request”.
The
links
take
you
into
JIRA
with
the
screen
promp0ng
what’s
required.
Let’s
look
at
this
in
more
detail.

86. Feature
Requests
Crea0ng
a
request
takes
you
to
JIRA,
and
requires
you
to
specify
a
summary,
a
component
(select
drop
down
for
op0ons,
they’re
the
products,
and
you
can
specify
more
than
one!),
assignee
(leave
as
“automa0c”),
reporter
(yourself,
search
by
name).

87. Product
Backlog
Let’s
look
at
the
third
secJon
in
detail:
Product
Backlog.
The
goal
of
this
secdon
is
to
see
what
work
is
queued
up
to
work
on
next,
defined
in
a
format
anyone
can
understand:
stories
define
what
value
is
gerng
to
what
person
for
what
reason,
and
bugs
define
funcdonality
that
use
to
work
but
currently
does
not.
Have
it
open?
Good!

88. Product
Backlog
• Few
porJons
to
pay
aFenJon
to:
– What
work
are
the
teams
going
to
take
on
next?
– What
are
the
teams
going
to
take
on
for
the
rest
of
the
year
at
a
high
level?
– How
do
we
prioriJze
the
work
to
be
taken
on?

89. Product
Backlog
Grouped
by
teams;
at
top
are
the
DNS
teams,
at
bojom
are
the
Email
teams.
Within
DNS,
we
can
see
short-­‐term
backlogs
for
DNS
Performance
and
Op0miza0on
and
DNS
New
Product
Development.
Within
Email,
we
can
see
short-­‐term
backlogs
for
Email
Deliverability
and
Email
Engineering.
Let’s
zoom
in
on
DNS.

90. Product
Backlog
For
each
team,
the
backlog
contains
the
sorted
list
of
bugs
and
stories
that
will
be
taken
on
when
the
current
sprint
wraps
up.
The
top
10
items
are
shown.
The
top
N
items
define
the
next
sprint,
where
N
changes
based
on
the
complexity
of
the
work
that
can
be
completed
in
under
two
weeks.

91. Product
Backlog
To
see
beyond
the
top
10,
you
can
click
the
“N
matching
issues”
link
at
bojom.

92. Product
Backlog
The
short
term
backlog
defines
the
work
to
be
done
between
the
next
sprint
and
about
6-­‐8
weeks
out.
The
long
term
backlog
focuses
on
larger
efforts
that
we
know
we’re
going
to
take
on,
between
about
2
months
out
to
1
year
out.
Clicking
the
tabs
changes
the
view.

93. Product
Backlog
There
are
two
priori0za0on
links;
one
shows
priority
of
just
the
stories
and
bugs,
while
the
other
includes
the
technical
and
business
sub-­‐tasks
that
describe
the
work
to
be
taken
on
in
detail.

94. Current
Sprint
Let’s
look
at
the
third
secJon
in
detail:
Current
Sprint.
The
goal
of
this
secdon
is
to
show
what
teams
are
working
on
now
in
the
current
sprint,
who’s
working
on
what,
and
how
efforts
are
progressing
within
the
sprint
(e.g.,
efforts
to
be
done,
in
progress,
in
QA,
and
complete)
toward
a
release.
Have
it
open?
Good!

95. Current
Sprint
The
rows
indicate
teams
(e.g.,
Data,
Marke0ng,
DNS
P+O,
Email
Deliverability,
etc.).
The
columns
indicate
states
of
stories
and
bugs
as
they
progress
through.
As
a
sprint
is
worked
on,
issues
move
from
lea
to
right.

96. Current
Sprint
Here
is
the
work
currently
being
taken
on
by
the
data
team,
described
in
the
form
of
stories
and
bugs.

97. Current
Sprint
Here
is
all
of
the
work
across
the
teams
that
has
yet
to
be
started.
Moving
lea
to
right,
the
work
goes
through
the
states:
In
Progress,
In
QA,
and
finally
Done.
When
the
work
is
released
to
produc0on
at
the
end
of
the
sprint,
it’s
removed
from
the
view.

98. Current
Sprint
To
move
work
from
one
state
to
another,
click
the
“Current
Sprint
Rapid
Board
with
Stories
and
Bugs”
link.
That
will
take
you
to
JIRA,
where
you
can
drag
and
drop
your
work
into
the
next
state.

99. Current
Sprint
To
see
the
individual
technical
and
business
sub-­‐tasks
that
compose
the
stories
and
bugs,
and
how
those
individual
items
are
progressing,
click
the
“Current
Sprint
Rapid
Board
Including
Tasks”
link.

100. Get
your
own
dashboard!
If
you’re
running
Confluence
and
JIRA
and
would
like
to
get
started
with
this
dashboard,
email
me
at
cvw@dyn.com
and
I’d
be
happy
to
send
you
the
code
and
help
you
set
it
up!

101. Course Title
Course Title
INSTRUCTOR NAME