►
From YouTube: Plan Iteration Retro - March 2020
Description
Plan Team hosts a quick retrospective on how we have been working to improve iteration across the stage :
- Thoughts on recent Iteration Office Hours with Sid
- Discuss recent examples of successful iteration
A
All
right:
well,
thanks
for
joining
for
our
plan.
Iteration
retrospective
working
through
you
know
we're
participating
in
this
whole.
You
know:
iteration
onboarding,
training,
they're,
trying
to
curate
and
make
advancements
on
server
beta
group
see
how
we're
gonna
go
through
a
couple
of
these
talk
about
the
issues
that
we
need.
You
know
the
training
issues
we
need
to
get
closed
and
Sarah,
so
this
will
just
hop
in
thanks
for
joining
so
progress
on
training
issues.
Again,
there's
just
videos
and
documentation
review.
It's
not
a
ton.
Those
would
be
April
3rd.
A
So
just
keep
that
in
mind.
Gabe
yep
you're,
not
a
manager,
you're
technically
done
great.
Go
thanks
for
keeping
onto
that.
Just
make
sure
you
check
the
boxes
and
close
the
issues
when
you're
done
so
they
don't
have
to
chase
this
down
and
ask
for
status
updates.
So
for
those
who
were
able
to
join
SIDS
iteration
office
office
hours
on
merge
20.
This
yeah
thoughts
concerns
specialize
specifically.
If
we
want
to
talk
about
the
individual
items,
I
got
reviewed
Donald
you
wanna
open
that
up
with
your
real
time,
come.
B
A
B
It's
not
in
that
playlist.
The
last
one
is
a
couple
weeks
back:
okay,
it
might
just
not
have
been
uploaded.
I'll
follow
up
that
I'll
share
that
out
with
a
group,
awesome
well,
yeah,
one
thing
I
found
of
interest
of
particular
interest,
just
because
it's
definitely
relative
to
what
we're
doing
is
around
real
time
and
I.
Just
got
me
thinking
like
was
there
anything
that
we
could
have
done
as
a
group
to
make
that
more
iterative,
because
real-time,
just
in
general,
has
been
an
issue.
B
C
Think
in
watching
the
iteration
video
that
Sid
and
Christopher
did
together.
I
think
it's
around
1920
and
timeline
basically
says
like
waiting
for
approval,
slows
down
cycle
time,
it's
incompatible
with
iteration
and
you
don't
want
a
dependency
on
another
team.
It's
like
super
bad,
so
I
think
it's
one
of
those
examples
where
I've
seen
that
across
the
board,
and
specifically
this
work
there,
we
almost
like
allowed
ourselves
to
feel
some
sort
of
dependency
on
another
team,
and
we
should
have
just
done
it
ourselves.
So,
yes,
I,
agree.
Sure,
just
on
it
to
start.
A
So
I
think
that's
good
I
mean
you
know.
This
isn't
I
think
it's
helpful
to
pull
out
any
improvements
or
thoughts,
not
just
specifically
iterating
on
works.
I
think
that's
that's
good
feedback
I
think
handoffs
are
even
harder
in
a
sink
environment
and
you
have
to
be
much
more
intentional
with
them.
So
I
think
that's
a
that's
a
good
point.
We
can
focus
on
and
try
to
get
better
any
thoughts
about
the
actual
breakdown
discussion.
Discussion
from
the
oppas
are
on
this
or
what
should
be
done
next
er
I.
C
Think
it's
not
a
good
trajectory
like
Chris,
followed
up
with
me
or
Christopher
called
it
with
me
in
slack
and
I
basically
said
that
most
of
credit,
for
that
goes
to
the
engineering
team
and
just
like
pushing
back
to
do
the
smallest
thing,
and
so,
like
I,
don't
know
if
you
can
get
much
smaller
than
having
one
field.
Updating
in
real-time
like
this
seems
like
to
me
and
not
even
updating
in
real-time,
literally
the
real-time
portion
of
it
is
just
sending
a
bully
into
the
front
end
and
saying
hey.
C
B
That
means,
but
I,
agree
and
I
think
Sid
even
called
that
out
as
a
great
first
iteration
is
just
focusing
on
one
component,
just
focusing
on
a
setting
isn't
giving
that
out
and
I.
Think
it's
interesting
just
looking
back
at
that
like
see
your
points
around,
instead
of
sending
all
the
data,
just
the
boolean
saying
that
this
change
thrown
out
was
another
thing
that
we
like
that
iteration
came
after
actually
looking
through
and
determining
that
you
know
again,
everything
out
would
be.
It
would
be
a
larger
ask.
B
B
Liked
how
I
liked
house
all
right,
real,
quick
before
him,
I
like
in
the
office
hours,
how
we
like
it's
not
just
the
iterating
on
technical
solutions,
but
also
like
iterating,
on
how
we,
like
I,
think
gray,
brought
up
something
about
discussing
or
how
we
reward
community
members,
but
talking
through
that
too,
and
talking
through
some
marketing
iteration.
It's
always
interesting
to
see
how
other
how
other
functions,
also
iterate.
B
A
E
Take
it
away
I
know,
I
did
a
really
great
job
with
the
requirements,
management
really
breaking
down
the
engineering
team
really
dope
in
and
found
and
broke
it
down
into
multiple,
much
smaller
issues.
So
everything
was
great
and
we
were
able
to
complete
a
bunch
of
those
in
12:9
and
we're
gonna
finish
up
at
1210.
I
just
want
to
point
out.
E
We
did
find
one
issue
with
this,
though,
is
that's
the
upcoming
releases
page,
which
is
that
auto-generated
thing
that
grabs
all
the
basic
issues
with
certain
labels
and
puts
them
on
for
like
the
product
timeline?
The
issue
with
that
was
the
requirements,
management,
MVC
issue
and
the
one
that
said
you
know
created
any
requirement
both
completed
in
twelve
nine,
so
there's
nothing
in
twelve
ten.
E
So
it
looks
like
if
you
look
at
that
upcoming
releases
page
looks
like
there's
nothing
going
on
in
twelve
ten,
because
I
didn't
want
to
put
a
direction
element
on
some
of
these
smaller
sort
of
infrastructure.
Type
issues
like
you
know
enable
the
feature
flag
and
those
types
of
things
aren't
really
Direction
items.
E
So
there
is
a
bit
of
a
disconnect
here
and
I
heard
back
from
sales
a
little
bit,
and
they
said
you
know
that
makes
it
hard
for
us,
because
when
we
go
on
the
field
and
say
hey,
this
is
all
the
stuff
that's
coming
out.
They
don't
see
requirements
on
there,
and
so
they
don't
know
how
they
can
track
that.
E
So
just
sort
of
a
word
of
warning
as
we
break
things
down
when
we
close
out
issues,
which
is
what
we
should
be
doing,
you
do
sometimes
lose
the
ones
off
that
page
off
that
upcoming
releases
page,
which
makes
a
little
bit
more
difficult
to
sort
of
show.
Your
roadmap
in
that
specific
example
and
I
got
some
feedback
on
that
sort
of
share.
E
I
mean
that
shows
anything
with
the
direction
label
apply
it
in
the
1210
release.
The
thing
is,
I,
don't
know
if
we
should
be
adding
it
directionally
to
things
like
you
know,
update
the
graph
QL
API,
that's
not
really
a
Direction
type.
It
doesn't
feel
like
a
direction
item.
It
is
because
it's
completing
requirements,
management
and
I
guess
in
direction.
They
want
everything
under
the
requirements:
management
MVC.
You.
E
It
clutters
things
up
so
there's
it's
kind
of
a
no-win
and
if
I
look
back
over
what's
left
in
the
epic,
none
of
them
in
the
titles
and
again
we
can
change
titles,
but
none
of
them
in
the
titles
directly
say
finished
requirements,
management
and
I.
Don't
want
to
update
the
titles
of
these
because
they're
very
descriptive
of
what
they're
doing
right
now
so
we're
kind
of
caught
in
this
odd
limbo
state
where
there's
nothing.
E
A
E
F
Yeah
I
thought
it
was
a
good
example,
mostly
because
I
saw
members
of
the
team
take
on
some
of
the
work
which
doesn't
seem
to
happen
very
often,
so
that
shows
that
the
work
was
broken
time
well
and
we
also
did
kind
of
remote
XP
thing
and
that
we
built
the
prototype
and
then
once
we'd
answered
our
questions,
we
threw
a
light
and
we
started
coding
it
from
scratch,
with
good
quality
built
in
and
so
yeah.
There
was
a
few
things
there.
We
also
benefited
from.
F
We
didn't
necessarily
keep
reviews
inside
the
team,
but
we
definitely
took
advantage
of
the
fact
that
we
have
reviewers
and
maintained
errs
on
the
team
to
speed
up
the
process
and
get
the
reviews
through
quicker,
so
yeah.
There
was
a
lot
of
a
lot
of
good
good
things
about
that.
We're
also
like
it
had
a
number
of
people
watching
it
hands-on,
PMS
sure
that
scope
was
kind
of
ruthlessly
cuts
at
all
times
anytime.
Anything
started
to
creep
in.
There
was
a
bit
of
a
moment
where
somebody
sort
of
went:
hey
hang
on.
F
Do
we
really
need
that
and
because
we
always
have
a
backlog,
we
have
a
second
iteration
full
of
stuff
that
we
could
be
buildin
if
we
had
the
time
if
we
had
spare
capacities.
So
we
always,
we
had
a
broken
down
nicely
that
way
as
well
and
where
we
could
always
say
well,
it'd
be
nice
to
have
that,
but
don't
build
it
we'll
build
this
instead,
if
we
have
extra
capacity
so
yeah
for
all
those
reasons,
I
nominate
the
JIRA
importer
yeah.
A
G
A
Yeah
I
think
also,
you
know
we
had
to
make
some
uncomfortable
early
cuts
when
we
started
talking
about
user
mapping
I'm
just
understanding
it
could
be
much
more
complex
and
not
something
we
could
fit
into
a
single
cycle.
Yeah
there's
another
one
Gabe.
You
have
a
great
question
on
there.
If
you
want
to
verbalize
that.
C
Yeah
so
I
think
that
cure
importer
is
like
the
the
epitome
of
collaboration,
I,
think
in
what
I
would
expect
at
all
the
development
product
design,
UX
interactions
to
look
like
a
kit
lab
but
like?
How
can
we
recreate
that
without
it
being
almost
like
forced,
because
we
have
to
write
daily
updates
to
our
leadership
and
it's
a
CEO
interest
item
and
those
sorts
of
things
like?
C
How
can
we
make
that
the
norm
so
I
actually
enjoy
I,
enjoy
working
in
a
more
collaborative
way
like
that
and
it's
more
hands-on
with
engineers
and
designers
as
we
were
going
and
iterating
and
cutting
things
and
making
decisions
on
the
fly?
So
it's
a
lot
less
wasteful
up
front
when
you
do
it
that
way,
but
just
how
can
we
recreate
that,
on
an
ongoing
basis.
A
Well,
I
mean
one
of
the
do
we
maybe
four
sets
of
features
or
something
that's
gonna
drive
value
and
knowing
it's
gonna
come
and
split
into
multiple
issues
like
do
we
maybe
focus
on
like
kick
ops
like
having
a
session
and
say:
hey,
here's,
the
idea,
who's,
the
thought.
Here's
the
current
proposed
brickers
the
proposed
proposal.
A
C
C
People
that
ended
up
working
on
it
and
I
wasn't
sure
who
that
was
gonna,
be
so
they
weren't
involved
in
the
decision-making
process,
and
so
it's
almost
like
what,
if
we,
when
we
identify
these
things,
they're
gonna
get
split
out
into
epochs,
and
during
the
planning
breakdown
phase
we
figure
out
who's
gonna
be
working
on
it.
You
know,
and
that
way
they
can
be
involved
in
the
decisions
in
the
cooperation
from
the
onset.
G
H
It
takes
more
time
for
me
good
for
all
those
things,
but
when
the
dirac
importer
came
in,
it
was
such
a
high
priority
that
I
just
intentionally
pushed
everything
out
of
the
way
just
focused
on
that
and
then
had
a
lot
of
synchronous
conversations
with
the
developers
and
aid
which
helped
to
speed
things
along
I.
Think
a
little
bit
but
I
know
that
that's
not
necessarily
the
way
we
want
to
always
operate
so
I'm
curious.
What
everyone
thinks
interferes
with
doing
this
approach.
More
often
I.
C
You
know
like
and
I
think
that's
where
it
kind
Elsa
goes
hand
in
hand
with
work-in-progress
lemons,
to
saying,
like
we're,
only
gonna
work
on
few
things
at
a
time,
but
being
able
to
see
those
things
like
tied
back
up
to
the
bigger
things
that
were
working
on
so
everybody's.
Looking
at
the
same,
like
that's,
the
whole
point
of
Kanban
is,
like
everybody,
looks
at
the
same
work
in
progress.
C
You
know
and
like
looks
at
the
flow
of
value,
basically
through
the
system
in
the
same
way,
so
that
could
be
a
cool
thing
to
do
to
build
that
feature.
I
guess,
but
I
agree
with
you
Holly.
It
is
like
when
I
sit
down,
I
have
52
dues
from
a
bunch
of
people
and
they're
not
like
high-priority
things,
but
I
feel
like
that
not
responding.
But
then
you
get
like
glossing
this
very
thorough,
managing
communications
and.
H
D
A
I
mean
I
think
that's
part
of
what
we're
trying
to
do
with
these.
Like
kickoff
issues
we
give
every
month
right,
it's
like
we're
pretty
explicitly
stating
like
priority
direction.
Items
I
mean
I
think
by
definition,
if
it's
got
a
direction
label
on
it,
it's
top
stat,
yeah,
but
I.
Think
how
do
you
then,
like
you
said
like
deal
with
all
of
them,
I.
F
It's
high
stakes
and
it's
cool
to
have
some
fun
high
stakes
at
one
of
its
people.
The
people
working
on
the
Giro
importer
really
enjoy
at
least
as
far
as
I
can
see
and
if
I
believe
what
I'm
told
they
really
enjoy
it.
But
for
that
reason
and
honestly,
I,
don't
think
it'd
be
a
terrible
thing.
If
an
each
milestone.
A
Like
that,
yeah
I
think
as
we
get
better
from
the
product
side
being
able
to
like
aggregate
data
on
usage
and
growth
and
be
able
to
tie
like
you
know,
for
example,
these
roadmap
improvements,
like
we
have
top
ultimate
customers
repeatedly
asking
for
it.
So
I
think
that's
something
if
we
can
communicate
the
demand
for
it,
as
well
as
in
the
results
that
helps
tell
that
story
and
help
motivation,
yeah
cool
and
the
interest
of
so.
D
A
B
So
I
was
just
gonna
say
it
be
nice
because
it
sounds
like
if
we
all,
as
a
team,
have
one
thing
to
focus
on
like
we
can
all
swarm.
On
that
thing,
we
can
all
we
can
all
groove
together
to
get
that
one.
The
engineers
UX
product
can
all
swarm
together
to
get
that
one
thing
done.
So
what
if
we
try
to
create
like
when
a
release
comes
up,
define
a
theme
for
that
release
and
it
can
even
just
be
one
like
epic
that
we
want
to
accomplish
within
that
release.
B
We
have
the
kickoff
issue
that
defines
what
this
is
going
to.
What
this
is
gonna
look
like
what
this
is
going
to
require.
We
create
a
slack
channel,
a
feature
slack
channel,
which
I
think
has
also
helped
with
the
jury
importar
just
having
that
slide
channel
of
everyone.
That's
involved
in
actually
building
it,
it's
kind
of
a
smaller
team,
and
it
can
even
include
everyone
within
that
groups
of
it's
a
portfolio
management
issue
or
epic
or
theme.
B
We
include
everyone
within
the
portfolio
management
engineering,
team,
UX
team
I
mean
that
feature
channel
and
then,
like
John,
said,
even
if
people
aren't
directly
working
on
that
specific
feature,
they
know
what's
going
on.
They
know
that
the
work
they're
doing
outside
of
that
feature
is
work
to
shield
the
people
that
are
working
on
that
feature
from
taking
on
other
work
like
just
I'm,
just
trying
to
think
of
action
items
of
anything
we
can
kind
of
take
from
the
things
we
did
well
in
that
your
importer
yeah.
A
No
I
think
that's
fair
I
think
you
know,
and
this
is
I
think
I'm
gonna
be
the
quintessential
product
manager
here.
I
think
I
want
to
balance
that
with
like
how
do
we?
How
do
we
find
a
scenario
where
we
can
actually
deliver
more
than
one
feature
every
30
days,
I
think
you
can
priority,
rank
it
and
stack
it,
but
I.
Also
I,
don't
wanna
get
in
a
scenario
where
it's
like.
We
have
one
priority
item.
That's
the
only
thing
we're
trying
to
get
through.
A
B
It
does
but
I
feel
like
when
we
get
so
spread
out,
which
were
we're
kind
of
at
now,
like
on
so
many
different
things.
That's
where
we
get
into
the
one
engineer
owns
one
task,
one
engineer
owns
and
another
everyone's
kind
of
siloed
in
there
one
specific
thing:
I'm
wondering
it.
So
if
we,
if
we
have
beans,
that
doesn't
necessarily
mean
that
we're
only
gonna
deliver
one
feature
milestone.
It
just
essentially
says
that
the
features
that
we
argue
in
deliver
are
all
related
and
they're.
B
G
Then
a
suggestion
training
towards
that
Keenan,
like
the
importer,
was
an
example
of
swarming
and
focusing
on
one
thing
across
all
of
Clan,
maybe
in
maybe
in
the
future.
We
try
one
per
group
like
one
for
project
management,
one
for
portfolio
and
one
for
certifying,
because
the
other
day
requirements
manager
is
actually
shipping
in
1210
as
well.
We
just
haven't
been
talking
about
that
and
focusing
on
it
and
granted.
Most
of
it
was
done
in
twelve
nine,
but
maybe
that's
a
way
to
enter.
It
is
so.