►
From YouTube: RCA Into Unfinished Features in Plan
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
so
I
put
this
all
together
like
right
back
at
the
beginning
of
the
quarter,
because
I
realized
we
had
a
lot
of
stuff
unfinished
and
one
of
the
reasons
I
felt
that
it
was
costing
us
philosophy
is
because
we'd
have
to
come
back
to
those
things
like
every
couple
of
months.
We'd
get
a
community
contribution
through
and
you'd
have
to
go
back
and
figure
out
like.
Where
is
this
thing?
How
far
along
did
we
get
it?
Where
did
we
leave
it?
What
status
is
the
future
flag?
A
Some
of
it's
not
behind
a
feature
flag,
technically,
there's
a
little
bit
of
a
security
issue
if
somebody
did
enable
it
and-
and
so
it's
better
to
go
through
and
find
out
like
why
some
of
these
things
are
there
and
what
we
can
do
about
it
in
future,
like
what
are
our
kind
of
blind
spots,
if
we
have
any
to
kind
of
prevent
this
happening
in
the
future.
What
could
do
so?
A
So
we
had
head
count
resets,
we
had
engineering
allocations,
redeployment
of
product
managers,
and
so
we
weren't
robust
at
all
to
this.
So
my
first
suggested
corrective
action
was
a
sensible
cap,
whatever
that
is
per
team,
whatever
on
new
deliverables
per
milestone
and
specifically
like
not
the
number
of
new
deliverables,
but
the
type
right.
A
C
Thank
you.
So
I
think
it
depends
on
the
items
and
the
milestone
honestly,
like
the
there
will
be
milestones
where
you
do
have
these
big
chunky
deliverables
right,
but
there
are
going
to
be
milestones
where
you
have
sort
of
like
smaller
things
like
even
product
planning.
This
milestone.
We
have
like
four
smaller
kind
of
buckets,
whereas
last
milestone,
we
had
one
big
one
right,
so
I
don't
know
if
there
can
be
a
blanket
rules.
C
The
other
thing
that
I
want
to
bring
up
is
that
if
we
get
into
a
situation
where
things
are
slipping
from
muslim
to
muslim,
that's
something
that
we
definitely
need
to
retro
and
figure
out.
What's
going
on
right
and
not
just
kind
of
like
keep
rolling-
and
I
know
like
in
project
management,
y'all
have
done
things
like
have
a
catch-up
milestone
right,
but
I
think
that's
one
of
the
things
that
we
need
to
be
sort
of
watching
and
acting
on
as
it's
happening.
A
C
E
So
knowing
what
the
velocity
of
the
team
is
understanding
if
issues
in
epics
are
like
big
things
are
refined
enough
to
where
they're
weighted
we-
and
we
know
our
velocity-
is
25
right.
We
can.
We
can
look
across
all
the
work
that
needs
to
be
done
and
pick
out.
25
worth
of
weight
that
we
want
to
commit
to
is
something
that's
like
a
deliverable,
and
that
can
be
all
one
theme
or
it
could
be
a
bunch
of
small
stuff.
E
D
A
What
am
I
hoping
to
achieve
limiting
themes?
It's
it's
kind
of
similar
to
the
work
in
progress
limits
that
we
did
like
as
absolute
limits
on
queues
except
you're,
saying
that
we're
gonna
put
it
onto
a
theme
so
in
other
words
like
you're,
not
like
as
an
engineer
working
for
a
week
and
a
half
on
requirements
and
then
having
to
switch
quickly
to
a
bug.
That's
in
epics
right
like
you,
because
there's
a
cost
to
contact
switching
and
you
pay
that
overhead.
A
A
They
know
instinctively
that
if
we've
set
a
goal
to
deliver
epic
links
by
the
end
of
the
milestone-
and
they
have
two
options
in
front
of
them-
they
know
which
is
the
most
important
option
to
work
on
first
thing,
with
almost
no
no
need
for
information,
radiators
or
consultation
with
managers.
Things
like
that
and
I
think
that's
really
powerful
and
useful.
A
A
So
when
you
get
to
the
next
milestone,
you
have
your
big
deliverable,
your
follow-ups
from
the
previous
milestone,
which
you
still
have
some
context
on,
provided
you
schedule
them
right
away,
and
then
you
have
your
bug:
security
issues
and
performance
tests
that
you're
trying
to
burn
down
as
well
so
like
if
you're
just
delivering
one
thing
like
you
still
have
plenty
of
other
work
to
do,
but
it
just
narrows
the
focus
a
little
bit.
You
know.
B
C
Yeah,
so
there's
like
a
couple
of
actionable
things
that
I
hear
is
one
is
like
trying
to
be
intentional
around
the
subject
area.
Even
if
it's
not
a
single
theme
right,
but
just
a
subject
area
to
reduce
context.
Switching
is
one
two
is
that
it
is
important
to
have
something
that
is
the
most
important
thing
in
a
milestone
right,
even
if
we
have
other
work,
but
just
having
one
thing
that
you
can
kind
of
rally
around.
E
Yeah,
the
other
thing
that
I
try
to
do
in
terms
of
like
to
help
that-
and
I
just
did
it
in
this
one
15
auto
planning,
because
mario
actually
asked
me
the
question
he's
like:
what's
what's
what
what
are
the
relative
priorities
of
these
things?
Right
and
I
was
just
like-
oh
cool,
that's
a
great
question
and
then
I
like
basically
listed
out
like
here's
the
things
like
relative
priority
that
we
need
to
do
and-
and
I
put
that
at
the
top
of
basically
above
the
themes.
E
So
that
way
like
anybody
looking
at
that
knows
like
this
is
the
highest
thing
that
we
need
to
do,
and
then
this
and
then
this,
even
though
there's
like
all
these
things
in
these
different
kind
of
themes,
from
quality
of
life,
iteration,
cadences
and
workouts,
I'm
fine
limiting
that
down
even
further
just
one
like
once,
iteration
cadences
are
kind
of
launched.
Then
I
think
we
can
just
I'm
hoping
we
can
have
just
one
which
will
be
work
items
for
a
long
time,
but
I'm
fine
doing
that.
D
I
mean
I
don't
really
have
a
problem
limiting
to
one
theme.
I
think
the
theme
from
certify
has
been
pretty
much
the
same
thing,
which
is:
let's
get
requirements
finally
shipped,
so
I
don't
think
there's
been
any
confusion
there,
I'm
happy
to
continue
with
that.
I
realized
that
there's
some
blockers
and
some
limitations
with
that.
So
I
think
that's
where
it
becomes
difficult
is
even
if
we
have
one
main
theme,
that
is
the
most
critical
thing
to
the
business
at
any
given
point
and
we
flow
that
theme.
D
If
it
does
become
blocked,
then
by
default
we
need
to
have
other
things
so
understanding
how
to
prioritize
those
other
things
in
a
way
that
keeps
progress
moving
is,
I
think,
really
important
just
to
ensure
that
we're
not
getting
distracted
with
the
secondary
things
when
something
gets
blocked
and
never
going
back
to
the
primary.
So
I
guess
we
just
need
to
make
sure
we're
on
that
same
page
but
yeah.
I
have
no
problem
planning
that
way.
A
If
there
are
blockers
upcoming
like
you,
can
de-risk
it
as
much
as
possible
by
doing
a
spike
the
month
in
advance
and
trying
to
identify
those
blockers.
Now
some
of
them
are
such
hard
blockers
that
we
can't
go
ahead
and
do
the
next
milestone.
Then
we
just
shouldn't:
do
it
right
until
those
points
are
gone.
D
Well,
I
think
that's
the
thing.
I
think
what
we
need
to
really
have
is
a
good
feedback
mechanism,
and
I
think
that's
what
we
might
be
lacking
here,
because
things
like
requirements
recognizing
that
there's
migrations
involved.
So
it's
a
really
good
example:
it's
something
that
has
to
be
spread
over
a
series
of
milestones,
because
we
have
to
do
certain
migrations
in
each
milestone
and
basically
nothing
else
like
it's
just
that's
how
the
nature
of
the
situation,
but
we
need
to
make
sure
that
feedback
mechanism
is
incredibly
crisp.
D
B
I
have
a
question:
are
we
defining
a
deliverable
as
something
that
is
going
to
be
delivered
to
a
user
or
just
a
piece
of
work
that
we're
going
to
get
done
in
a
certain
time?
Like
so
say,
we
have
something
that
we
know
is
going
to
take
like
four
milestones
and
there's
no
way
to
really
break
it
down
into
into
something
that
we
can
provide
to
the
customer
to
user
within
a
milestone.
D
The
way
we've
documented
it
right
now
and
from
everything
I've
read
a
deliverable
is
an
agreed-upon
piece
of
work
that
will
be
completed
in
that
milestone.
It
does
not
have
to
be
a
release
post
item.
It
does
not
have
to
be
a
customer-facing
feature,
so
in
that
sense
we
could
commit
to
a
deliverable
of
making
one
more
step
in
requirements,
migrations
and
that
might
just
be
two
days
worth
of
work
for
somebody
and
then
there's
nothing
more.
They
can
do
that
milestone,
but
that's
that
was
the
deliverable
agreed
upon
that's
being
delivered.
D
We've
succeeded
in
that
deliverable
recognizing
that
it
doesn't
actually
impact
our
customers
in
any
way
shape
or
form,
but
it's
absolutely
critical
to
maintain
this
cadence,
or
else
things
just
keep
slipping.
So
we've
tagged
as
deliverable.
We've
prioritized
it
as
a
deliverable
and
therefore
the
goal
is
to
deliver
that,
because
it
is
necessary
either
to
a
customer
facing
feature
or
to
a
downstream
effort.
That
is,
you
know,
in
progress.
B
D
Been
a
huge
problem
and
I
think
the
the
issue
is:
we
made
a
commitment
about
a
year
ago
to
migrate
to
work
items
and
it's
it's
taken
on
a
lot
of
different
forms,
and
I
think
we've
made
iterative
improvements
and
I
think
I'm
very
satisfied
with
you
know
how
the
decisions
have
been
made.
I
think
they're
the
right
decisions
made
at
the
right
time.
D
The
difficulty
is:
there's
no
customer
facing
output
until
we
come
out
the
other
end
and
with
these
long-lived
things,
it's
very
easy
for
anybody,
product
engineering,
whoever
to
get
distracted
by
some
shiny
new
feature.
That
would
give
immediate
value
and
that's
not
wrong.
The
problem
is
that
just
delays
ever
getting
value
out
of
all
this
effort,
we've
put
in
so
right
now
we're
actually
in
a
bit
of
debt
right
now.
D
A
I'm
aware
of
time,
do
we
want
to
skip
the
second
one
and
have
a
separate
async
chat
about
community
contributions
and
how
we
can
deal
with
those
like
because
it
seems
like
it's
a
whole
separate
topic
where
escapes
is
kind
of
related
to
what
we're
talking
about
already?
Does
that
make
sense
cool
gabe?
Do
you
want
to
talk
about
anything
specific
to
do
with
or
filtering
or
iteration
cadences.
E
Yeah,
I
updated
the
issue
with
sort
of
more
context
there,
but
I
think
in
sort
of
both
of
these,
I
think
with
the
or
filtering
the
problem
is
that
we
we
never
did
like
a
clear,
refinement
right
and
then
like
we.
We
then
split
fp
and
back
end
issues
out,
and
then
we
got
feedback
that
we
needed
to
kind
of
make
some
changes
with
the
ui,
but
like
the
the
time
to
for
all
that
stuff
to
happen
was
months.
E
And
then
we
were
three
months
into
it
and
learned
that
we
were
blocked
by
the
issue
list.
The
view
issue
list
and
we
should
never
have
started
in
the
first
place
right,
and
so
I
put
in
our
the
release
plan
for
like
five
releases
in
a
row
and
was
like
you
know,
but
but
it
sort
of
just
fizzled
out
for
lots
of
different
reasons,
and
I
think
that's
where
I
am
in
agreement
with
things
that
are
epic
level
to
have
a
dri
engineer.
E
Do
a
spike
on
it,
but
also
have
whoever
does
the
spike
be
the
one
who
owns
at
least
the
first
initial
mvc
of
it
right.
So
that
way,
they
have
the
context,
that's
sort
of
what
happened
with
iteration
cadences,
where
alexandria
took
the
lead
from
back
in
and
split
a
bunch
of
stuff
out,
but
then
got
allocated
to
workspaces
and
then
all
of
it
kind
of
sort
of
got
lost
right
and
we
lost
the
momentum
and
there's
like
a
lot
of
things.
E
I
think
I
learned
from
that,
but,
like
I'm
noticing
with
like
a
lot
of
things
that
ended
up,
slipping
it's
it's
because
there's
not
enough
consensus
on
how
something
is
gonna,
be
built
and
then
like
what
steps
need
to
be
taken
to
build
it.
So
then
we
get
into
like
places
like
where
we
are
now
and
we're
uncovering
like
with
work
items.
E
For
example,
we
can't
launch
tasks
because
the
url,
the
like
basically
breaks
in
various
places-
and
it's
almost
like
we
did-
we
didn't
uncover
that
until
three
days
before
the
code
freeze
and
so
some
of
those
things
almost
like
wonder
if
it
is
the
spikes,
are
really
important
and
then
also
having
clear
dies,
be
responsible
for
like
refinement
and
documenting
the
steps
to
take.
So
that
way,
anybody
who
does
come
behind
them
knows
what
needs
to
be
done.
E
A
Whenever
I
hear
that
requirements
kind
of
like
become
more
apparent
as
the
work
continues,
I
always
think
like
somebody
should
have
just
asked
you
a
question
at
some
point
prior
to
this,
like
to
clarify
right
and
one
of
the
things
that
the
spike
allows
is
like
one
month
of
interaction
between
pm
and
engineer
to
directly
feed
back
to
each
other.
Do
you
know
what
I
mean
like
I
said
at
the
minute?
It
feels
a
little
bit
like
pm.
A
Sets
the
requirements
engineer
sort
of
organize
as
best
they
can
around
those
requirements,
and
then
they
start
to
work
and
a
whole
bunch
of
complexity
is
revealed
yeah,
whereas,
like
you
kind
of
set
some
time
aside
and
you
shorten
the
feedback
cycle,
and
you
say
like
okay,
it's
like
9
24
hours.
Instead
of
being
the
middle
of
the
milestone,
when
you
find
out
that
this
requirement
can't
be
satisfied,
do
we
want
to
do
something
else.
E
Yes,
that's:
I
think
that
I've
always
found
it
most
effective
when
we
are
able
to
effectively
talk
about
trade-offs,
whether
what
we're
prioritizing
and
scheduling
as
a
whole
or
how
something's
going
to
be
built
because,
like
in
my
mind,
I
always
have
an
assumption
about
how
something
should
work
right.
It's
not
reality.
E
That's
fine
for
me
because,
like
melissa
said
I
I
can
tell
you
in
rough.
I
mean
I'm
open
to
engineering
feedback
on
like
the
rough
sequencing
of
things,
but
we
can
literally
seek
without
the
work,
probably
for
the
next
12
months.
If
we
wanted
to-
and
it's
all
very
known
it's
there
are
some
things
we
still
need
to
validate
like
what
we
want
the
ui
to
look
like,
but
but
technically
speaking,
like
we
sort
of
know
everything
that
we
need
to
do,
I'm
sure
that
will
change.
E
B
E
That's
one
thing
that
holly
said
that
she
was
always
found
lacking
is
her
struggle
with
how
to
get
engineering
more
involved
earlier
when
she
was
working
on
design
stuff.
I
think
that
would
be
a
great
mechanism
alignment
mechanism
to
give
the
designer
the
engineer
like
for
in
the
pm
all
for
sort
of
collaboration.
The
validation
track
like
one
month
before
things
start
or
we
want
to
prioritize
doing
it.
A
C
A
A
A
Have
that
kind
of
level
of
focus
a
shared
goal?
You
know
the
human
element
of
of
this,
like
you
can't
hardly
quantify,
but
also
hard
to
ignore.
Like
I
mean
when
you
have
a
goal
and
everybody's
aligned
on
the
goal
and
the
goal
is
like
completely
clear
yeah
just
it
can
be,
it's
just
a
much
faster
and
more
satisfying
way
to
work
so
yeah.
You
can
look
at
that
as
well.
D
E
Other
one,
I
don't
know
how
to
make
this
a
corrective
action,
but
I
know
it
is
a
root
cause
and
looking
at
a
lot
of
things,
especially
like
is
maintaining
a
stable
team,
so,
like
iteration
cadences,
probably
would
have
shipped
a
long
time
ago.
Alexander
didn't
have
to
get
allocated
to
workspaces
a
lot
of
the
stuff
like
the
ore
filtering
stalled
because
heinrich
got
allocated
the
database
stuff,
and
some
of
this
is
outside
of
our
control,
but
the
more
we
can
have
and
maintain
a
stable
team.
E
A
Yeah
and
like
far
down
below
that,
but
also
a
factor-
and
I
wouldn't
like
recommend
as
a
corrective
action
is
that,
like
I
don't
think
it's
a
coincidence
that
we
had
zero
security
issues
and
the
milestone
after
we
got
that
we
did
epic
links
in
one
milestone.
I
don't
think
that's
a
coincidence,
I'm
not
saying
it's
the
only
thing.