►
From YouTube: Defend Planning Breakdown - Threat Management Group
Description
Defend engineers working with PM to breakdown upcoming issues into components, clarify requirements, and identify work boundaries.
A
You
know
we've
heard
time
and
time
again
that
if
we
can
deliver
smaller
slices
of
technology
to
our
customers
and
not
define
our
issues
in
these,
these
sort
of
large
epic
type
efforts
that
we've
seen
over
the
last
couple
of
milestones
that
both
engineers
are
gonna
be
happier
because
we
you'll
be
moving
through
issues
faster.
Things
will
hopefully
be
a
little
bit
more
clear
and
what
you're
building
but
will
also
be
more
reliable
to
our
product
managers.
A
For
you
know,
estimates
on
when
we
what
we
think
we
can
commit
to
in
a
given
iteration,
so
this
she's
acceptable,
then
it'll
move
into
the
scheduling,
step
and
just
pick
up
where
we've
always
had
the
workflow
process,
yams
of
PM's
new
capacity
planning
they
sign-off
issues
for
additional
grooming.
We
don't
expect
this
meeting
to
complete
the
grooming
for
it.
For
each
of
these
issues
there
will
be
additional
grooming
and
if
the
answer's,
no,
that
it
goes
back
to
the
PMS
and
they
will
help
answer
the
the
questions
that
we
had.
A
A
The
hope
is
that
people
are
spending
time
reviewing
these
issues
prior
to
this
meeting,
so
I'm
not
gonna,
spend
a
lot
of
time
waiting
for
people
to
do
that
now
and
think
of
their
issues.
Unfortunately,
if
you
know
we
don't
get
participation,
the
assumption
at
this
point
is
if
this
was
good
to
go
so.
A
No
I
got
a
good
point,
so
you
know
I,
don't
know.
The
message
came
out
very
clear
to
everybody
that
the
hope
is
that
you
can
commit
you
know,
maybe
an
hour
or
so
before
this
meeting,
to
doing
your
homework
and
making
sure
that
you've
prepared
questions
that
you're
not
reading
through
this
for
the
first
time.
Basically,
so
is
there
anyone
that
this
is
familiar
to
you
that
would
like
to
rave
any
concerns
or
logical,
break
points
or
boundaries
of
work.
I.
B
B
C
There's
there's
no
unified
interface
for
checking
all
system
events
throughout
gitlab,
it's
all
contextual.
So,
within
the
case
of
an
issue,
description
or
an
issue,
activity
feed
you'd
see
the
notes
for
that
issue.
So
that
is
one
component
of
this
is
creating
a
or
show
these
notes
within
the
context
of
the
vulnerability
at
UI.
Okay,.
B
B
A
E
E
E
The
way
we
built
the
functionality
for
the
first
iteration
is
when
you
change
the
status
you
kind
of
get
a
fake
system
event
where
it
gives
you
the
system
event
line
like
you
would
see
here,
like
Michael
Scott,
changed
vulnerability
status
to
confirmed
then
below
it.
We
give
the
user
the
opportunity
to
add
a
comment
to
actually
each
status.
They
were
to
like
confirm
it.
Then
they
could,
in
this
block
area
the
bottom
of
the
vulnerability.
They
could
type
a
comment
as
it
pertains
to
that
confirmation
same
with
dismissal
and
same
with
resolving
it.
A
C
I'm
thinking
about
this
in
a
bit
of
a
different
way
than
that,
where
I
don't
think
that
this
would
involve
so
two
of
the
logical
ways
we
break.
That
down
is
like
the
front
and
work
in
the
backend
work
and
the
UX
work,
and
the
effort
looks
good
here
for
the
system
notes.
But
it's
it's
a
bit
so
system
events
occur
when
regular
interactions
occur,
like
changing
the
status
from
open
closed.
C
So
from
the
front
end,
we
just
need
to
show
the
notes
and
the
back
in
generates
these
system
notes
from
the
various
events,
but
it
seems
like
that
is
a
as
a
result
of
an
action.
So
if
you
were
to
add
a
comment,
you
know
generate
a
system
known
as
well.
Maybe
like
I,
don't
know
if
that's
a
condition,
one
that
we
want,
but
it
but
I
would
see
that
as
a
bit
separate
and
comments.
Mm-Hmm.
D
E
C
A
A
A
If
we
were
to
create
another
issue
off
of
this
I'm
so
used
to
a
world
where
we
have
subtasks
to
define
that
I,
don't
know
if
that
necessarily
I
mean
it.
That
is
one
logical
break.
What
do
you
guys
think?
Do
you
think
it
makes
sense
to
have
separate
front-end
issues
from
Quebec
and
issues
for
something
that's
of
this
size?
Is
that
always
helpful,
or
does
it
create
other
problems
around
collaborating
between
the
two
areas?
F
F
B
People
could
see
how
look
I
mean
that
might
be
overkill
for
this
one
or
overdoing
it
for
this
one
I'm
just
thinking
of
the.
If
people
can
see
it,
then
they
can
even
with
mocked
up
data.
Then
they
can
get
a
feel
for
how
it
may
operate,
but
I
can
see
reasons
for
not
doing
that
too,
but
just
to
thought.
What
do
you
think
yeah.
F
That
we
could,
we
could
do
that
if,
if
I
could
maybe
get
an
example
of
how
the
the
shape
of
the
data
would
look
like,
even
if
it's
not
going
to
be
finalized,
that
would
help
a
lot
so
that
it
wouldn't
be
like,
like
we
wouldn't
have
to
code
against
a
you
know,
that's
going
to
be
vastly
different
than
what
the
final
copy
is
gonna
be,
but
then
you
know
we
if
we
as
long
as
we
get
that
we
can
at
least
get
started
in
parallel
with
the
back
end.
So
it's
a
good
point.
B
It
remind
you
of
the
the
iteration
interview
that
Christopher
did
with
Sid
that
it's
a
good
idea.
We
don't
always
have
to
do
this
right,
but
just
soon,
as
you
consider,
is,
have
the
UI
in
place.
Even
if
it's
junk
data,
so
people
get
a
feel
for
it
and
then
build
out.
The
backend
is
not
a
bad
way
to
go.
A
A
E
E
A
E
A
E
A
Okay,
so
I,
it
sounds
to
me
like
the
main
action
coming
out
of
the
discussion,
for
this
issue
is
to
create
a
front
finish
you
off
of
it
that
can
be
worked
independently
from
the
back
end
issue.
We've
already
got
some
mock-ups
I,
don't
I'm,
not
clear
on
the
answer,
then
around
the
comments.
Do
we
create
a
separate
issue
and
there's
a
dependency
here?
This
is
what
the
requirement
is
to
add.
E
The
system
notes
will
get
us
past
parity,
so
if
we
want
to
consider
how
to
plan
in
commenting
simple
commenting
ability,
so
you
don't
need
we're
not
planning
on
markdown
or
quick
actions
right
away.
I
wouldn't
think
we
would
knowing
how
other
groups
have
tried
to
do
commenting
seen
it
take
a
while.
So
maybe
yeah
just
another
issue
for.
A
G
Absolutely
well
I
was
gonna.
Ask
is
that
Andy,
something
that
we
would
potentially
want
to
do
than
the
commenting
on
the
issue
or
and
the
vulnerability
first
and
then
come
back
to
this,
so
that
we
can
leverage
the
commenting
in
place.
Or
is
this
a
true
kind
of
a
third
state,
its
comment?
It's
a
system
note
or
it's
a
comment
or
a
sorry
assistant.
Oh
plus
comment,
I.
E
Think
the
natural
progression
would
be
probably
go
commenting
first
and
then
rip
out
the
way
we
have
it
today
and
then
do
system
notes
so
that
we
have
system
notes
and
general
commenting.
You
know
just
putting
just
saying
like:
oh,
let's
put
commenting
and
the
vulnerabilities
that's
going
to
be
a
chore,
so
doing
that
first
might
be
appropriate,
maybe
more
appropriate
than
going
system
notes.
F
E
E
E
Now
it's
more
a
question
of
continuity.
So
if
we
do
commenting
first
that
we
can
kind
of
discuss
that
as
a
feature
like
now,
you
can
comment
and
it
doesn't
have
to
be
incumbent
on
a
status
being
there
or
not.
You
can
just
type
a
comment
in
and
then
we
can
add
system
notes
later
and
refresh
how
we
were
doing
comments
initially.
A
Okay,
so
we
find
I
think
we've
made
some
progress
and
highlighted
some
areas
that
maybe
would
have
been
overseen
and
grooming.
I
don't
feel
like
this
is
ready
to
move
on
to
scheduling
and
grooming.
That
being
said,
given
some
of
the
things
that
have
come
up
Matt,
what
do
you
think
to
do?
What
should
we
revisit
this
specific
issue
since
it's
at
the
top
of
your
list?
Once
we've
got
some
of
these
details,
a
little
bit
more
fleshed
out.
G
It
was
such
good
stuff.
I
was
saying
no
based
on
the
conversation
here.
It
definitely
sounds
like
this
has
got
to
be
a
follow
on
and
we've
got
a
missing
issue
for
commentary
that
needs
to
go
in
front
of
it
and
kind
of
in
parallel
sounds
like
Andy.
You
and
I
need
to
kind
of
think
about.
Do
we
want
to
go
for
the
same
kind
of
behavior
or
do
we
want
to
make
something?
Maybe
a
little
bit
different
with
I
guess
from
input
from
engineering
to
see
if
this
whole
changed
stay?
C
I'm
not
sure
that
the
back
end
would
change
regardless
of
this
decision,
though
so
breaking
out
that
work,
maybe
I
think
that
could
be
done
any
time
that
basically
involves
Creed's
system
notes
internally
when
things
change
and
then
expose
in
it
somewhere.
If
we're
just
talking
about
how
that's
going
to
integrate
the
comment
system,
that
can
happen,
but
that's
that's
depending,
but
if
we
break
out
that
work
I
think
at
least
part
of
it,
you
know
is
good.
A
C
A
C
A
A
G
The
idea
here
is
to
start
by
taking
what
would
appear
in
the
security
dashboards,
so
the
list
of
vulnerability,
detections
and
making
a
simple
CSV
export
of
that
data
and
the
use
cases
people
can
use
that
for
internal
compliance
needs
and
the
case
of
the
customer
that
requested
if
they
actually
provide
this
kind
of
information
to
their
clients,
for
whom
they're
developing
software
to
prove
that
they
have
run
a
certain
number.
You
know,
scam
types
and
that
they
lack
critical
or
abilities
when
things
are
released
to
production,
so
yeah,
that's
pretty
much
it
it's
taking.
G
G
So
very
subtle:
well,
you'll,
see
they're
just
about
the
high
dismissed,
we're
adding
a
new
icon
to
the
screen.
There's
a
little
download
icon
and
oh
you
don't
have
to
close
that
unit.
Okay,
yeah!
So
then,
once
you
actually
do
hit
the
download
it's
going
to
be
a
little
modal
confirmation
or
no
sorry.
This
is
the
the
new
your
future
indicator.
G
B
C
B
Think
it's
a
matter
of
you
know,
that's
a
good,
so
customers
want
this
in
a
specific
format.
Do
we
know
what
they
want
to
import
it
in
I
mean
CSV
is
great,
for
you
know
just
about
anything,
but
you
yeah.
Is
there
specific
security
standard
out
there?
That's
rest-based
or
XML,
based
that
customers
might
want
to
import
it
into.
Oh,
you
know
expand
it.
You
know
talking
about.
Maybe
future
things
do
they
want
it
in
a
you
know,
a
human,
readable
format.
That's
that.
A
B
G
Absolutely
so
that's
what
we
backed
off
to
what
they
originally
asked
for
was
a
PDF
report.
With
all
these
kind
of
you
know,
configuration
settings
or
whatever
and
ultim
we
came
down
on
CSV
is
the
challenge.
The
the
root
challenge
is.
It
is
really
difficult
or
impossible
for
them
to
get
the
data
cleanly
out
of
the
get
lab
system,
so
they
don't
ever
really.
G
B
Should
we
have
a
we
have
a
header
line
in
the
first
row,
explaining
what
each
field
is
and
I
think
we
probably
should
so
people
know
what
it
is.
Let
me
import
it
if
the
field,
unless
the
field,
unless
it's
brutally
obvious
he's
probably
a
header
field,
it'd,
be
great,
actually
I.
Guess
if
you
could
put
together
an
example.
This
is
what,
for
this
data,
here's
what
the
CSV
would
look
like
and
that
would
give
us
a
target
to
go
towards.
A
C
A
These
are
questions
going,
I
think
need
to
be
answered.
Do
you
guys
not
necessarily
saying
that
these
need
to
be
answered
to
not
call
this
broken
down
for
planning
I
feel
like
some
of
these
can
be
defined
as
we
go
into
grooming,
especially
the
the
data
itself.
I
guess
my
out
there
going
back
to
our
goal
of
this
meeting
and
what
we're
trying
to
answer
are
the
requirements
clear
enough.
Do
we
understand
what
the
goal
is
or
the
intent
of
this
issue?
Does
anyone
have
any
more
questions
on
that?
A
A
A
G
C
D
A
Or
update
that
deciding
I
would
like
to
get
into
a
world
where
we
don't
just
make
decisions
and
comments
and
issues,
and
when
we
come
to
our
decision,
whether
it's
a
group
or
an
individual
that
they
are
reflected
in
the
description
of
the
issue,
to
reducing
the
amount
of
scrolling,
you
have
to
do
to
get
all
of
the
requirements
for
an
issue.
So
Matt.
Would
you
please,
instead
of
commenting
on
the
issue
of
take
the
descriptions
and
reflect
that
absolutely.
A
Right,
we
are
two
minutes
back,
so
I'm
an
inch
or
two.
So
that's
great,
it's
better
than
none
I
thought
of
respect
for
time,
we'll
find
other
times
to
continue.
In
this
conversation
to
some
degree,
we
might
have
to
limp
along
in
our
previous
way
of
planning,
which
puts
a
lot
more
dependencies
on
the
EMS
and
grooming,
but
going
forward
I'd
like
to
get
ahead
of
these
conversations.
A
So
we're
not
you
know,
rushing
to
get
through
a
big
list
of
issues
just
prior
to
planning
for
a
milestone,
but
this
is
sort
of
an
ongoing
thing
and
as
new
issues
get
created,
we're
talking
about
less
than
minute
time,
but
that's
gonna.
Take
us
a
little
bit
and
I
think
this
has
been
really
successful,
despite
the
fact
that
we
just
did
two
issues.
So
thank
you
all
for
your
time.
I
will
share
the
recording
both
in
the
agenda
and
it
will
postpone
today's
and
yesterday's
out
on
YouTube.