►
From YouTube: Plan Iteration Retrospective 2 - 2020-04-03
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
But
yeah
it's
like
hard,
you
don't
you
don't
know
what
you
don't
know
right,
that's
one
of
those
things
and
it's
that's
where
their
collaboration
of
like
all
right,
let's
flow
everything
out
and
like
everyone
maybe
swarm
on
this,
and
what
do
we
miss?
What
scenarios?
What
edge
cases
are
we
missing
here
so
that
that
piece
of
collaboration
is
really
helpful
as
a
designer.
B
B
Okay,
real
quick,
sorry
because
this
one's
this
one's
interesting,
it
is
a
bad
example
of
a
and
thing
we
could
have
done
better
at
iterating,
because
typically
I
feel
like
we
have
too
much
in
that
first
iteration
and
with
this
one
we
kind
of
didn't
have
enough
in
that
first
iteration,
we're
saying
that
we
we
missed
something
in
that
first
iteration,
just
an
observation!
No,
no!
Really,
nothing
really
beyond
that,
but
so
it's
a
little
interesting
compared
to
some
of
the
other
examples.
We
have
okay.
D
I
also
think
it's
interesting
that,
like
a
lot
of
these
issues,
have
come
up
like
you
iterate
to
get
feedback
from
customers
quickly
right
and
in
this
case
we
we
didn't,
show
anything
to
the
customers.
As
far
as
I'm,
aware
of
no
one
in
the
wider
community
raised
any
issues
with
the
security
and
looking
through
the
issue
and
like
linking
to
where
the
concerns
came
from
asked
you
the
fact
that
we
have
confidential
issues
that
might
have
keys
and
the
security
issues
descriptions,
and
then
we
want
to
make
them
not
confidential.
In
public.
D
Like
efforts
been
fixed,
we
don't
want
any
that
information
to
never
be
traceable.
So
it's
like
we.
We
raised
the
problem
for
ourselves,
but
we
didn't
iterate
with
customers,
so
I'm
just
wondering
like
if
there's
something
in
getting
it
in
the
hands
of
the
select
group
customers
more
quickly
to
get
feedback
more
quickly.
You
know-
or
at
least
I
get
involved
in
them
in
the
process.
So,
like
a
lot
of
times,
we
build
things
for
ourselves
and
not
for
our
customers.
So
no
just
notice
that
trying
to.
E
So
one
of
the
things
I
was
wondering
like
I
put
it
in
this
section
and
I
should
probably
move
on,
but
so
I
picked
these
two
issues
not
really
because
I
thought
that,
but
not
because
I
thought
I
could
pick
out
ways
we
could
have
iterated
better
but
because
they're
issues
that
we
expected
to
get
done
in
one
milestone,
and
we
didn't
and
I
thought
that
would
probably
people
might
have
some
idea.
Why
and
I'm
wondering
like
when
we
get
an
issue
like
say:
health
status.
E
Health
service
was
an
interesting
one
because
top
of
mind
because
it
was
I
believe
twelve
nine
we
could
have.
We
could
have
possibly
delivered
something
in
twelve
nine
and
we
didn't.
We
took
a
forward
into
twelfth
and
I
could
be
wrong.
I
could
be
a
milestone
head
there,
but
what
we
could,
what
we
started
with
was
editing
a
health
status
in
the
sidebar
and
then
showing
the
health
status
somewhere
like
in
the
epic
tree
or
whatever
and
I.
Remember
like
asking
you
kenan.
E
I
remember
asking
and
you
know:
can
we
ship
this
in
the
sidebar
alone?
I
knew
you're
kind
of
saying.
Well,
it
doesn't
really
deliver
any
value
in
the
sidebar
or
the
kind
of
conflicts
as
well
with
something
we
have
in
the
handbook,
which
is:
does
it
make
things
worse,
and
if
it
doesn't
make
things
worse,
you
know
just
ship
it.
So
what
I
was
wondering
is
like
what
would
be
the
strategy
for
a
p.m.
to
add
that
to
release
post
like
would
you
if
we
had
just
shipped
it
in
the
sidebar?
E
C
Yeah
yeah
in
retrospect
you
know-
maybe
maybe
that
was
the
wrong
call
on
my
part,
but
we
also
we
all.
We
had
a
lot
in
flight
and
I
think
it
was
count.
I
think
there
was
also
just
like
well.
If
we
delay
this,
it
drops
a
little
bit
below
the
line
and
we
can
move
some
of
the
like
a
roadmap
stuff
but
I.
C
You
know
if
we
just
look
at
that
in
isolation
and
that
would've
been
the
wrong
call
and
we
should
have
just
push
the
issue
status
out
on
its
own
and
then
you
know
we
could
have
right.
We
could
say
hey.
We
have
individual
issue
status,
that's
what
that's
for
release
post
worthy
and
then
the
next
follow
up
is
in
now.
You
can
aggravate
it
at
the
epic
level.
There's
counts,
here's
the
view
we
could
walk
into
it.
C
So
I
think
that's
good
feedback,
and
you
know
looking
at
that
decision
in
a
vacuum,
yeah
I
would
have
probably
made
a
different
choice.
Now,
looking
back
yeah.
E
I
mean
like
I
I
agreed
with
you
at
the
time.
It's
just
what
it's
just
watching
those
videos
on
iteration
like
it
just
moves
things
into
a
different
frame.
Right,
like
I
mean
they
hint
they
sort
of
promote
iteration
at
a
really
really
fine
level
like
and
when
you
watch
that,
and
then
you
move
your
your
frame,
you
kind
of
look
back
at
that
decision
and
I
kind
of
think
well,
actually
yeah.
It
would
have
like
fit
completely
within
the
frame
to
delete
that
Picard
to
ship
up,
because
it
didn't
make
anything
worse.
E
D
I
Chi,
taking
a
slightly
different
approach
in
it,
I
would
have
wanted
us
to
iterate
on
that
way
like
behind
a
feature
flag
and
if
you
slice
it
up
into
like
I'm
gonna,
add
this
thing
to
the
issues
have
our
first,
the
next
most
valuable
thing
is
this
and
at
some
point
you
can
kind
of
feel
like
okay.
This
is
at
a
point
now
I
think
there's
a
minimum
amount
of
value
to
the
end
user.
D
So
now
I'm
gonna
put
it
in
their
release
post
right
like
so,
you
slice
it
in
these
a
critical
feature
slices,
and
you
only
do
one
of
the
time
and
then
like
at
some
point,
I
think
you
can
realize
okay
well,
this
is
at
least
it
doesn't
make
things
worse.
It
actually
makes
things
just
a
little
bit
better.
That's
when
I
would
put
it
in
the
really
supposed
yeah.
That's
just
me,
yeah.
F
No
I
again
I,
think
I,
agree
with
that
and
I
did
John's
question
that
he
asked
in
the
doc,
like
he
said:
does
the
release
percent
but
shipping
earlier
less
valuable
features?
Absolutely,
in
my
opinion
right
and
so
you
could
see
us
just
constantly
iterating
and
delivering
as
things
become
ready
and
then
PM's
and
eum's
and
UX
decide
like
when
to
Gabe's
point.
When
you
get
to
a
critical
mass
of
a
given
feature
that
you
think
is
worth
talking
about,
then
you
make
a
release
post
and
their
release.
Question
then
simply
is
a
it's.
F
G
G
We
want
to
make
sure
that
whatever
we
provide,
an
initial
thing
has
something
the
user
can
actually
see,
which
is
why
the
requirements
management
has
taken
long
enough
to
get
out
necessarily
and
we're
still
not
delivering
what
I
would
call
minimum
functionality
we're
just
simply
at
a
viable
stage
of
being
able
to,
you
know,
add
requirements,
but
the
point
was
we
needed
enough
there
that
they
could
actually
see
it
if
it's,
if
it's
incrementing
on
functionally,
we
already
have.
I
completely
agree
when
we're
introducing
something
brand
new.
G
We
have
to
be
careful
not
to
release
something,
that's
half-baked,
so
people
get
a
horrible
place
their
mouth
for
it
upfront.
So
you
almost
need
to
be
cognizant
of
when
you
release
it
into
the
release
post
and
when
you
sort
of
market
it
to
make
sure
that
there's
enough
there
that
you
have
something
positive,
that
people
walk
away
going.
Oh
look:
this
is
a
great
first
iteration.
Not
this
is
completely
half-baked,
like
I'm
not
going
to
look
at
it
again.
G
F
A
C
And
the
discussion
was
like:
well,
alright,
let's
split
up
into
functionality
right
so
like
okay,
instead
of
having
confidential
epics
a
thing
it's
like.
Well,
you
can
create
new
ones,
you
can
toggle
existing
ones,
etc.
We
split
it
up
and
then,
when
we
actually
got
into
the
minutiae
of
how
this
would
happen,
we
have
something
that
theoretically
might
not
we'll
be
done
in
a
single
release
like
what
do
we?
How
do
we
approach
that?
C
Because
there
is-
and
this
is
something
I
think
it's
come
more
and
more
apparent
to
me
and
I-
think
you
know
I,
like
the
conversations
we
have
because
we're
getting
there
is.
You
know
the
iteration
is
not
just
a
product
manager
task,
because
we
can
talk
about
functional
right,
but
I
am
not
equipped.
C
Nor
will
I
ever
be
in
in
a
position
to
talk
as
an
expert
about
how
complex
the
data
the
data
work
is
going
to
be
or
the
backend
work
is
going
to
be,
and
so,
when
we
kind
of
peel
back
a
layer
at
the
onion,
we
we
find
out
well
now.
This
is
a
lot
bigger.
Well,
we
run
into
them.
Ok,
we
need
to
find
an
MVC
that
we
can
do
in
a
single
release
to
thrive
value
and
it's
valuable
enough
to
talk
about
it
as
an
MVC.
C
But
how
do
you
do
that
when
a
lot
of
what
we
need
to
do
is
requiring
some
very
deep-seated
database
work
and
I?
Think
you
made
a
comment
that
every
piece
of
functionality
add
actually
makes
additional
ones
more
complicated
because
we
have
we're
expanding
the
data
structure.
I
think
I,
don't
have
a
good
answer
for
that.
Yet,
and
it's
kind
of
scary,
yeah.
E
I
mean
not
me
neither,
but
but
I
did
think.
One
thing
was
interesting
in
the
interview
between
Sid
and
Christopher.
Two
things
in
that
variable.
One
of
them
was
really
interesting.
Who
said
said
like
like
product
managers
can
allocate
engineers
time
engineers
can
feed.
Oh
yeah,
that
allocation,
so
you
know
I,
know
I
think
what
they
were
getting
out
was
basically,
like
you
can
say,
here's
confidential,
epics,
here's
my
proposal
and
you
you've
kind
of
scoped
the
feature
dying
as
small
as
you
possibly
can.
E
The
engineer
can
then
say
veto
it
and
say
this
can't
be
done
in
one
release
and
that's
the
point
at
which
you
kind
of
work
together
to
continually
share
the
dine
on
till
its
fits
into
it's
a
one
release
like
so
so
in
that
one
yeah,
it's
interesting
because
a
lot
of
the
iteration
videos
say
that
we
should
have
something
that
can
ship
them.
One
release
right,
so
it's
like
well.
E
If
it
can't
go
on
one
release,
what
can
we
take
away
and
that's
why
I
thought
that
was
interesting,
because
you
can't
you
start
getting
down
to
the
level
of
what,
if
we
just
shipped
it
in
graph
GL
the
first
release
like
what
if
there
was
no
UI
so
now,
there's
no
dependency
on.
You
know
UX,
and
maybe
we
could.
You
know,
shorten
the
dependency
on
front-end
and
no.
We
just
have
database
and
back-end
and
like,
but
is
it
useful
I,
don't
know
how
many
people
are
gonna
create
a
confidential
at
the.
E
G
No
I
did
I
really
did
appreciate
that
interview,
though,
because
I
do
like
the
idea
I,
you
know,
I
think
it
empowers
the
engineers
to
be
able
to
say
no.
This
is
not
broken
down
correctly
or
no.
This
is
the
wrong
approach
and
I
think
that's
really
valuable
feedback
I'm
happy
to
receive
that
and
I
actually
welcome
that,
because,
again
to
kinas
point,
we
can
break
the
features
down
by
value
drivers
or
by
customer
view,
but
it's
very
difficult
for
us
to
understand
on
the
back
end
or
the
front
end.
G
What
is
the
minimum
step
we
can
take
on
the
back
end
and
then
that's
what
these
conversations
can
lead
is
well.
Okay.
If
we
take
this
minimum
step,
that's
a
deliver
value
and
like
the
graph
QL
example.
Well,
in
that
case
it
doesn't
look
like
it
will
deliver
value
so
can
we
can
we
then
talk
further
and
figure
out
how
we
could
make
it
a
value
delivering
feature?
G
C
A
great
conversation
to
have
right
now,
the
the
next
question
immediately
is
at
what
point
of
the
cycle
should
we
be
having
that
conversation
and
I
think
this
comes
into
the?
Why
this
is
complex
now
and
you
know
Justin,
let
you
hear
this
one
like
SPMS,
we
talked
about
things
we
want
to
have
in
a
release
post
and
a
kickoff
video,
that's
public
and
on
the
internet
and
watched
by
many
people
internally.
C
What
this
is
a
great
example:
hey.
We
talked
about
working
on
confidential
epics.
Now
we
we,
you
know
peek
behind
the
curtain.
We
realize
it's
a
much
bigger
problem.
Now
we
have
something
out
there
saying:
hey
we're
gonna,
do
this
and
now
we're
definitely
probably
not
gonna,
be
able
to
do
it
in
this
release
like
if
this
puts
us
contingent,
because
the
kick
off
video
is
this
forward.
D
At
the
timeline
we're
supposed
to
be
making
having
those
conversations
with
engineering
a
week
before
our
release,
kickoff
right,
like
the
planning
breakdown,
type
stuff
and
like
those
all
those
trade,
offs
discussions
and
I,
don't
think
that
that
necessarily
happens
like
I.
For
me,
it's
more
like
at
at
Hawking,
like
okay,
I,
think
we're
gonna
start
working
on
this
thing
soon.
Can
we
get
like
you
know?
How
are
we
getting
to
implement
it?
You
know
and
it'll
be
like
conversations
back
and
forth
and
I'll
go.
D
Do
some
other
things
and
come
back
a
week
later
and
make
conversation,
maybe
over
may
not,
but
I
don't
know
like
that's
kind
of
where
I
don't
like
looking
in
the
30
days
is
too
big
of
a
batch
size.
So,
like
thinking
about
queuing
here,
you
want
to
keep
your
batches
as
small
as
possible,
and
I'd
like
I,
would
rather
have
conversations
about
how
we
can
do
vertical
slices
like
deliver
an
increment
of
value
and
like
I,
linked
in
the
question
to
do
to
like
article
about
it.
D
But
it's
a
kind
of
thing
where
I
would
rather
focus
on
this
and
less
on
the
kickoff
video
yeah
I
can
having
these
conversations
with
engineers
like.
How
can
you
really
like
write
a
fault
like
all
of
our
issues,
instead
of
them
being
split
on
function
or
split
on,
let's
do
the
whole
graph,
QL
API
and
then
we'll
do
the
other
thing
even
here,
but.
C
D
G
G
F
So,
let's
yeah,
let's
think
about
how
to
propose
an
iteration
to
the
kickoff
product
kickoff
itself
and
see
if
we
can
find
a
way
that
doesn't
make
PM's
feel
like
they're,
trying
to
they're
gonna
be
held
accountable
to
deliver
on.
What's
exactly
said
in
a
kickoff
video,
because
I
think
that's
the
rub
here
and
then,
however,
we
want
to
go
and
I.
You
know
I,
like
the
vertical
feature,
slice
concept
and
like
how
we
want
to
go
break
things
down
from.
F
G
F
E
Sure
so
yeah
does
anyone
want
to
suggest
any
updates
that
we
can
make
I
know
you
just
suggested
one
there,
but
the
thing
that
sticks
out
to
me,
for
example,
is
that
I
recently
pulled
the
team
on
whether
they
wanted
to
continue
to
split
just
but
waiting
every
month
or
not
to
split
it,
in
other
words,
to
pair
up.
So
both
groups
have
project
management
and
then
the
portfolio
in
certify
teams
to
wait.
E
Everything
I
took
a
look
at
it
this
month
and
there
were
like
40
items,
40
ready
for
the
milestone
40
in
planning
breakdown,
and
that
seemed
like
a
lot
of
work
and
I
can't
ignore
the
fact
that
many
of
the
team
voted
to
actually
split
the
work
this
time
and
have
project
management,
people,
wait,
project
management,
stuff
and
portfolio
and
certify
people
wait
for
wholly-owned
certify
stuff.
So
maybe
there's
something
there.
We
could
do
where
we
split
the
workloads
along
domain
expertise
and
then
try
to
move
move
it
back.
E
Each
milestone
so
I
think
on
the
products
timeline
we're
supposed
to
get
the
issues
to
wait
by
the
fourth
of
the
month,
but
that
never
really
happens
and
that's
fine,
but
if
we
can
move
it
back
like
a
little
further
each
month
and
I'm
wondering
how
we
could
do
that,
maybe
by
getting
engineers
involved
earlier
in
the
breakdown
or
half
a
milestone
ahead,
break
down
for
a
little
while
like
so.
In
other
words
like
we
have
issues,
we
think
we're
gonna
tackle
a
milestone
ahead
and
we
start
to
break
those
down
as
well.
G
I
would
be
personally
very
happy
to
have
less
stuff
that
needs
weights
on
it
in
that
bucket
in
a
given
time,
if
we
could
have
it
be
done
on
a
more
frequent
basis
and
I
don't
know
if
that
makes
it
easier
for
your
engineers
or
not
so
again.
This
goes
back
to
what
makes
the
most
sense,
but
I
would
much
rather
get
weights
for
two
or
three
things.
Every
week
then
have
to
queue
up.
G
G
Rather
somebody
spend
you
know
an
hour
to
each
week,
tackling
one
thing
and
really
understanding
it
and
getting
it
I,
don't
say
right
because
I
don't
think
they're
getting
it
wrong
now,
but
I'm,
getting
it
diving,
deeper
and
making
sure
they're,
confident
and
having
higher
increased
confidence.
Then,
having
this
list
of
a
bunch
of
things
that
they're
trying
to
just
churn
through
for
a
day.
D
Yeah
I
would
rather
see
us
continuously
waiting
things
right,
and
so,
if
we're
working
towards
being
more
combat
driven,
it's
a
whole
system.
So,
like
that's,
why
you
have
should
have
work
in
progress
limits
for
your
planning
breakdown
as
well,
and
your
scheduling
and
you
don't
pull
anything
in
to
get
weighted
or
broken
down
until
there's
room
to
do
it
and
the
stream?
D
Basically
so,
like
I,
think
that
doing
that
would
prevent
these
like
giant
batch
sizes
of
waiting
things
that
then,
like
may
or
may
not
be
super
accurate
and
may
or
may
not
ever
get
done.
You
only
wait
the
things
that
are
going
to
get
scheduled
because
they
got
pulled
into
that
queue
or
that
process
and
then,
as
soon
as
they're
done
it
they're
going
to
move
into
the
next
process.
So
it's
like
a
pole
system
downstream,
which
is
where
I
would
like
to
see
us
not
like
a
batch
system
that
we're
doing
now.
B
Yeah
and
just
give
you
it
also
mentioned
somewhere
around
weighing
bugs
and
I,
feel
like
a
lot
of
the
waiting.
That's
done
right
now
is
I,
don't
know
percentage-wise,
but
I
feel
like
a
lot
of
them
are
bugs
that
engineers
have
to
go
through
and
wait.
I
don't
really
see
a
lot
of
value
in
weighing
bugs,
because
by
the
time
someone's
by
the
time,
an
engineer
is
doing
the
investigation
to
figure
out
how
complex
it
is
to
really
fix
a
bug.
They
can
probably
just
go
in
and
fix
it
at
that
point.
B
D
G
I
would
actually
advocate
for
a
post-mortem
weighting
of
the
bugs,
basically
to
your
point
and
go
in
investigate
them
figure
out
what
needs
to
be
fixed
at
that
point,
you
can
fix
them.
The
only
reason
I
would
advocate
for
than
throwing
a
weight
on
at
the
end
is
like.
Oh,
this
took
me
a
little
bit
of
time.
You
know:
go
back
to
the
waiting
scale,
I
put
what
it
took
you.
So
it's
an
after-the-fact.
G
It's
simply
from
a
metrics
perspective,
to
understand
how
much
weight
we're
pushing
through
and
give
and
release,
because,
if
you're
doing
for
bugs
that
are
weights,
1
&
2,
that's
taking
away
you
know
or
210.
You
know,
weight
out
of
features
and
I
think
we
just
need
to
make
sure
we're
accounting
for
that
somewhere
or
else.
We're
gonna
see
a
really
odd
graphs
when
it
looks
at
productivity
and
velocity
I.
Actually.
D
Like
that,
that's
the
point
like
the
way
that
I've
always
done
it.
Is
you
never
wait
bugs
or
chores
or
any
like
technical,
that
you
only
wait,
features
like
in
that
the
weight
represents
customer
value
units,
so
you
see
if
it's
fluctuating
then,
like
you
know,
something's
wrong
like
reproducing
to
me:
defects
are
we
like
whatever
and
then
it
kind
of
warrants
investigation?
It's
like
how,
like
your
velocity,
is
the
representation
of
not
like
how
much
you
deliver,
but
how
many
customer
value
units
you're
delivering
right.
G
E
E
B
The
only
concern
I
have
with
trying
to
figure
out
who
is
going
to
work
on
an
issue
earlier
on,
so
they
can
contribute
to
the
breaking
down
and
weighing
is
that
it
kind
of
I
don't
know
about
discouraged
is
but
like
it
removes
some
of
the
flexibility
we
have
for
kind
of
collaboration
or
for
other
people
to
pick
up
issues
within
that
larger
initial
issue
or
epic.
But
again,
let's
let's
talk
about
that
in
them
in
mark
what.
D
Well,
backlog,
oh
yeah,
that's
traditionally
what's
been
like
here's
something
we
need
to
get
down
the
backlog
and
like
that
way,
you
do
it
just
in
time
like
I
want
to
start
thinking
in
terms
of
like
how
it's
wasteful,
if
we
estimate
things
ahead
of
time
and
they
don't
work
on
it
for
a
long
time.
So
how
can
we
do
everything
just
in
time,
so
we
estimated
only
when
we
need
to
right,
which
is
right
before
we
should
start
working
on
it.
G
Not
doing
the
milestone
allocation
in
the
same
way,
I
think
that's
what
the
PM's
are
trying
to
push
is
I,
don't
like
trying
to
do
it
all
at
the
beginning,
because
then
it's
usually
you
don't
have
all
the
data.
I'd
rather
do
you
know,
add
things
the
milestone
on
a
week-by-week
basis.
When
somebody
runs
out
of
work,
we
say:
ok,
let's
add
it
to
mouseland,
let's
pull
it
weight
it
at
the
milestone
and
then
basically,
milestone
is
a
line
in
the
sand.
This
is
where
we
got.
This
is
what's
done.
G
D
Think
that's
what
what
I
did
previously
when
I
did
extreme
programming
is
once
a
month
we
did
release
playing
with
the
engineer's
where
we
talk
about
things
in
an
epic
level
right,
not
necessarily
the
granular.
Here's
everything
we're
gonna
get
done
down
to
tea,
but
here
are
the
themes,
and
then
you
would
like
agree
on
those
and
put
some
rough
order
of
magnitude
estimate
on
it
and
then
each
week
we
do
iteration
planning.
There
was
literally
only
an
hour.
D
We
would
demo
what
we
did
a
week
before
and
then
we
would
talk
about
what
we
want
to
commit
to
getting
done
this
week
and
we
would
break
those
stories
down
estimating
and
then
like
work
that
week
and
just
redo
that
cycle.
So
that
way
we
were
only
estimating
things
in
granularity
just
in
time.
We
were
only
committing
to
things
a
week
at
a
time,
but
we
are
still
progressing
towards
our
things.
F
Let's
think
offline,
how
we
uncouple
the
the
sort
of
stakeholder
release
post
cadence
from
what
we're
trying
to
do
here
as
a
team
I,
don't
having
a
good
answer
right
now,
but
I'd
rather
us
do
the
right
thing
for
the
team
and
then
I
can
figure
out
with
you
guys
how
to
kind
of
back
into
what,
whether
it's
sales
that
needs
information
or
Eric
or
Scott
or
whoever,
but
I'd
rather
us
feel
unencumbered
from
that
going
forward
here.
So
just
ignore
it
and
we'll
have
to
solve
for
it
later.
I.