►
From YouTube: Plan stage planning weekly - 2020-02-05
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
Okay,
recording
started
planned
weekly
looks
like
we
have
a
fairly
oh
actually
I,
have
a
team
update,
we'll
start
with
that
we
have
a
new
front-end
engineer,
starting
on
Monday.
Believe
it's
Monday.
Let
me
check
yes,
Monday
I'll
put
more
details
in
our
channel
but
excited
to
bring
a
nother
front-end
engineer
on
board.
Maybe
next
week
we'll
go
through
the
hiring
plan,
which
I
think
is
official
now
for
the
upcoming.
A
For
now
this
fiscal
year,
it's
pretty
high
up
there,
but
I,
don't
know
if
you
came
in
marker
or
Gabe
know
what
the
product
hiring
plan
is,
but
I
think
we
have
a
pretty
good
feel
on
that
engineering
side.
So
we
can
share
that.
You'd
show
what
the
plans
are
next
week,
I.
C
Hires
I
can
speak
though,
but
yeah
so
we've
already
hired
the
new
group
PM
they're
starting
or
he
is
starting
and
we
and
then
we
have
a
rep
for
one
more
p.m.
and
so
I
think
the
general
plan,
as
it
was
outlined
in
the
fiscal
21,
bottoms-up
planning,
you'll,
split
project
management
into
and
then
backfill
from
an
engineering
and
design
standpoint
up
to
like
the
full
team
and
then
we'll
have
a
decade
gird
for
boards,
but
I
kind
of
the
way
I'm
thinking
about
it.
C
It's
sort
of
like
a
moot
point,
so
I'm
hoping
within
the
next
few
weeks.
So
you
can
get
our
list
of
opportunities
together
and
kind
of
start,
focusing
on
like
the
things
that
are
the
highest
value
across
the
entire
stage.
So
more
or
less
a
lot
of
for
product
teams
within
fully
staffed
proc
teams
within
the
plan
stage
is
the
target
for
this
year.
C
A
C
So
like,
as
you
can
see,
across
the
entire
planned
stage,
we
has
historically
been
delivering
about
97
weight,
the
last
few
pre
consistent
there
and
the,
but
we
have
371
open
or
like
issues
weight
committed
to
twelve
eight.
So
like
we're
a
good
what
280
over
allocated
there.
Some
of
that
is
in
the
project
management
group.
A
large
portion
of
it
is
you
kind
of
kind
of
noticed,
there's
a
ton
of
issues.
C
That
way
like
we're,
setting
better
expectations
with
stakeholders
and
let
the
wider
community,
and
hopefully,
if
we
get
that
opportunity
to
list
of
all
trees,
nailed
down,
we'll
be
able
to
then
like
prioritizing
those,
instead
of
just
like
kind
of
randomly
doing
a
bunch
of
stuff
which
is
sometimes
feel
like.
We
do
because
issue
tracking
and
issues
is
like
an
interesting
catch-all
for
tons
of
different
issues,
so
we're
gonna
have
to
figure
out
itself
at.
C
That
up
and
support
the
engineering
effort
there
so
I
think
part
of
the
solution
to
getting
increasing
I
guess,
weight
completed
and
also
increasing
in
more
throughput
is
breaking
things
down
into
smaller
pieces,
both
from
an
issue
M
our
standpoint,
so
we're
gonna
be
focusing
on
that
pretty
heavily
over
the
next
several
releases
and
start
practicing
it
and
getting
better
at
doing
so.
Just
because
I
think
it
will
de-risk
everything
and
hopefully
make
it
easier
to
parallelized.
Work
is
up
to
us
any
questions
about
that.
D
B
C
So
next
item
I
think,
like
we
discussed
and
I've
discussed
with
the
aims
and
some
PM's
the
idea
of
like
working,
partes
limits
and
kind
of
whatever
boils
down
to
is
like
it
seems
contradictory
to
like
being
async
first
and
then,
like
you
know,
if
you
get
blocked
on
something
pulling
in
something
else
to
work
on
it.
So
you
get
unblocked
but
I
guess
like
I
kind
of
want
to
just
have
a
discussion
around
like
what
are
the
underlying
goals
of
using
working
progress
limits.
C
But
and
how
can
we
leverage
is
I'm
not
like
to
increase
our
throughput
by
removing
bottlenecks
and
improving
processes
so
like?
Where
are
things
getting
so
like?
If,
if
you
had
work
in
progress
limits
and
let's
say
they're
10
and
you
get
blocked
on
something
and
there's
not
a
slot
for
you
to
start
another
item
like
what
do
you
spend
your
time
on
and
I
guess,
that's
kind
of
like
what
we
need
to
understand
is
like.
Where
are
the
bottlenecks
in
our
process
and
then
when
you're
blocked?
Or
you
don't
have
time
like?
C
How
can
we
deploy
resources
to
fixing
the
process
changing
the
process?
Improving
it
so
the
the
bottleneck
gets
removed.
You
know
it's
almost
like
incremental
improvement
of
process
just
as
much
as
like
incrementally
shipping
features
and
capabilities.
So
general
discussion
I'd
like
to
just
see
what
our
goals
are
and
how
we
can
like
have
a
sane
approach
towards
using
working
for
artists
limits,
but
then
also
improving
our
process
as
a
part
of
that.
A
A
10
total
so
yeah
just
having
a
whip
limit
of
10,
pretty
in-depth
or
maybe
for
each
each
column
or
each
product
phase
having
a
whip
limit
of
of
10
on
for
project
management
just
to
start
off
and
then
see
what
we
can
see
what
we
can
see,
what
kind
of
data
we
can
get
from
that,
and
we
may
need
to
make
adjustments
yeah.
We
can
a
to
write
off
of
that.
C
Is
it
possible
right
now
to
create
a
dashboard
and
periscope
that
has
the
more
or
less
the
cycle
time
free
the
average
cycle
time
for
each
stage?
So
how
long
does
something
sit
and
ready
for
development
on
average?
How
long
do
something
sit
and
then
dev
on
average,
how
something
to
sit
sit
and
like
blocked
on
average
in
an
interview,
so
it
was
like
it's
just
the
average
amount
of
time
that
each
issue
stays
in
that
given
state
is
that
possible.
I
wish.
E
E
B
A
Yeah,
there's
I
know
there's
issues,
and
there
was
a
lot
of
discussion
about
a
year
ago
about
making
workflow
steps
as
making
one
primitive.
I
can
look
up
those
issues
if
you
want
to,
because
that
was
on
on
us
on
project
management,
so
I'll
look
to
see
if
I
can
find
those
issues,
there's
a
lot
of
good.
There
were
a
lot
of
videos
and
a
lot
of
conversations
around
around
that,
and
maybe
we
should
resurrect
those
conversations,
I
think.
C
Some
of
that
stuff's
being
discussed
in
cycling,
Alex
and
customizable
stages
and
whatnot,
so
I
also
look
because
I
know
that's
what
I
was
expecting
y'all
do
from
that,
but
and
I
think
that
might
be
in
beta
or
something
maybe
in
a
carry
but
I
guess
if
we
can't
track
that,
that's
fine,
that's
a
goal
to
get
to
so
I
think
that's
one!
You
had
like
when
you're
doing
combo,
like
that's
how
you
understand,
which
which
cycle
or
which
stage
has
like,
is
the
biggest
bottleneck
so
like.
C
Then
how
can
we
get
more
database
maintenance
on
our
team
or
remove
that
constraint
and
it's
like
if
the
goal
then
becomes
like
not
just
delivering
issues
but
fixing
the
overall
throughput
of
the
system
and
like
by
removing
one
constraint
of
time
so
that
everything
starts
moving
faster
for
everyone
and
I?
Think
it'll
be
hard
to
have
like
quantitative
data
to
direct
us
to
the
largest
constraint
without
seeing
cycle
times,
but
we
could
probably
do
a
qualitative
stab
at
it
at
some
point.
So
just
be
thinking
about
that.
C
The
other
thing
I
was
gonna
say
is
like
you
know
we're
in
this
case
that,
if
we're
gonna
start
doing,
you
know
a
working
part
summit
within
the
project
management
group
of
10.
There's
22
my
progress
right
now.
What
happens
when
like
how?
How
are
we
going
to
communicate
out
to
the
rest
of
team?
They
move
their
issue
from
in
dev
into
in
review.
What
do
they
do,
then?
You
know
like
look.
C
E
C
C
C
Well,
I
think
that's
good
for
now.
Let's
just
get
that
discussion
going
so
I
don't
want
to
not
discuss
it.
The
other
thing
kind
of
in
that
same
line
is
there's
two
schools
of
thought
with
like
how
you
manage
projects,
and
you
can
like
do
the
scrum
type
thing
where
you
right
now.
We
do
monthly
releases
and
that's
too
large
of
a
time
span
to
make
commitments
upfront
in
a
lot
of
ways
because
things
change
evolve.
C
You
learn
something
once
you
get
started,
and
so
the
way
the
teams
deal
with
is
they'll
have
like
week-long
iterations,
where
they
like
have
a
smaller
chunk
of
work
that
they
commit
to
and
plan
for
for
a
given
like
week
and
then
that
lesson
like
reset
their
expectations
that
their
commitments
the
next
week
based
on
what
they
learned
in
that
week,
and
so
it's
just
like
a
faster
cycle
time.
That's
one
approach,
it's
more
like
I,
guess,
sprinty,
whatever
it
and
then
the
other
approach
is
like
looking
for
continuous
improvement
via
something
like
Kanban.
C
Where
you
look
at
cycle
time,
you
use
work-in-progress
limits.
You
like
look
at
Li
times,
and
so
we
don't
have
data
really
for
either,
but
we
can.
We
should
support
both
in
the
product
anyway.
So
I'm,
just
more
curious,
like
which
one
do
you
like,
are
you
leaning
towards,
because
I'm
I
like
Kanban
a
lot
more
having
done
this
for
many
many
years,
especially
like
it
of
product?
It's
the
maturity
of
ours
with
the
body
moves
like
backlog,
but
I
didn't
know.
C
A
Yeah
so
I'm
kind
of
the
same
way
I
see
value
in
go
into
one
of
these,
at
least
as
opposed
to
what
we're
currently
doing
with
a
month
long
releases,
because
the
problem
I
see
with
one
long
releases
is
that
a
lot
of
times
we
tend
to
kind
of
fill
our
like
for
large
feature.
Requests
we'll
filled
like
a
5
we'll
take
the
entire
release,
just
because
that's
kind
of
the
time
that
we
have
associated
with
that
large
feature.
A
If
we
were
to
go
over
from
either
shorter,
iterations
or
Kanban
I,
don't
know
why,
but
just
also
the
same
way
in
past
experience
with
more
combat
has
seemed
to
work
and
when
we've
been
trying
this
kind
of
hybrid
approach
that
we're
doing
it's
just
easier
to
I,
think
plan.
I
think
engineers
have
a
little
bit
more
of
an
opportunity
to
determine
what
they're
working
on
through
Kanban,
because
it's
just
like
to
have
a
list
of
things
that
they
can
pick
up.
A
C
Yeah
I
think
that's
part
of
the
problem.
It's
like
having
milestones
would
be
easy
to
predict
if
we
had
lead
time
so,
like
we
think
on
bond.
Those
are
the
metrics
use
a
cycle
time
which
is
like
how
long
something's
it's
a
given
process,
and
then
you
have
lead
time.
So
how
long
does
something
set
from
once?
It's
like
quote-unquote
started
until
it
is
on
production,
and
so,
if
you
know
what
the
lead
time
is,
you
can
even
have
lead
time
by
issue.
C
Wait
so
I
assume,
like
that
kind
of
breakdown
you
can
I,
can
look
at
everything
that
is
in
the
like
backlog
and
tell
you
when
it
will
be
done.
Based
on
that
right.
So
it's
it
says
this
is
how
you
set
those
expectations,
and
so
that
way
we
can
know
if
we
know
hourly
time,
we
can
know
when
we
prioritize
something.
What
milestone
is
going
to
follow,
be
right,
good,
all
right,
so
you
get
the
same
level
of
predictability.
It's
just
a
different
metric
and
I.
C
Think
that's
where,
like
the
the
milestone,
really,
what
it
is
is
the
version
it's
a
software
version,
it's
a
release
and
it's
when
something's
gonna
get
packaged
into
release
and
I
think
we
can
still
do
like
kind
of
a
kickoff
an
overview
of
what
we're
targeting
for
a
given
version,
but
only
if,
like
in
any
case,
we
know
what
like
hourly
time
is,
or
we
know
what
our
velocity
is,
and
we
have
some
way
to
kind
of
predict
that
out
so
I
think.
That's
why
the
metrics
are
really
important
but
and
getting
lead.
C
I'm
gonna
put
a
note
for
myself
to
follow
up
on
on
customizable
cycling,
Alex
cuz,
the
way
it
was
being
designed
if
I
remember
correctly,
you
could
create
your
own
report
with
your
own
stages
on.
It
spoke
to
a
group
or
project
or
a
subset
of
labels.
So
if
that's
there
that
will
give
us
cycle
time
and
then
it
also
should
give
us
the
irregular
lead
time
if
it
works.
The
way
that
I
was
expecting
it
to
work
so
I'll
Faulk
and
see,
if
that's
ready,
yet
anything
else
to
discuss
here.
B
Sorry
taught
me
right
after
it
stays
yeah,
so
we're
talking
about
this
a
little
bit
last
night
in
slack
and
I,
think
John
we
were
open.
You
could
shed
some
light
like
what's
what's
the
DB
review
process,
it's
it
feels
like
we
get
a
lot
of
items
come
in,
say,
maybe
we're
just
talking
about
stuck
in
that
phase
in
review
and
I
realized.
I,
don't
actually
know
what
that
process
looks
like
so
I'm
just
trying
to
to
learn.
Yeah.
E
Nevertheless,
if
there's
a
database
change-
and
it
likes
a
migration-
and
even
sometimes
when
it
doesn't
alter
the
database
itself
but
alters
data
in
the
database-
and
it
requires
the
database
review
anything
that
requires
the
database
review
has
to
go
to
the
reviewer
first
and
then
ultimately
to
a
maintainer
I
think
up
until
Christmas,
we
had
one
maintainer
database
maintainer.
Now
we
have
three
yeah.
It's
still
not
like.
It's
still
definitely
a
bottleneck
like
across
the
company
that
go
across
the
department
and
but
it's
better
than
it
was
but
yeah.
E
A
E
So
I
think
the
I
think
it
is
like
it
is
really
well
rillettes.
Definitely
and
there
is
an
option
but
I
think
the
same.
As
with
regular
back-end
reviews,
you
can
choose
to
pick
somebody
with
domain
expertise.
The
labels
are
used
for
when
the
EMR
has
been
reviewed.
So
the
mr
requires
review
there's
a
label
for
that
when
it
has
been
reviewed,
there's
a
label
for
that
and
when
its
final
approval
has
happened,
there's
a
label
for
that
as
well
and
but
again
like
most
database.
Changes
are
also
going
to
have
back-end
changes.
B
Then
you
guys
have
a
do.
You
have
a
process
for
keeping
track
where
that
stuff
or
escalating
if
it
sticks
for
a
while
I'm
just
trying
to
say
like
we
need
to
scratch
something
like
that.
It's
like
essentially
a
bottleneck
for
a
lot
of
value
delivery
across
the
board.
Right
with
that,
and
it's
great
that
we're
we've
got
3x
more
than
we
had
Christmas
like
I.
Don't.
B
Know
I'm
looking
at
that,
like
that
I'm
adding
the
progress
indications
on
the
roadmap,
and
you
know
with
knowing
that
that
we
have
some
customers
waiting
for
that
like
what
do
we
do
when
something's
stuck
for
a
long
time,
and
is
there
a
flag
we
can
reigns
or
how
do
we?
How
do
we
bubble
it
up
to
a
point
of
discussion
if
something's
in
sintra,
yeah,.
E
I
mean
I'm,
not
sure
I'm,
not
sure
if
the
workflow
of
people
of
the
maintainer
is
like
how
to
keep
track
of
all
this
stuff.
I
know
the
from
our
end,
like
we've,
been
trying
various
things
and
one
of
them
is
to
sort
of.
If
the
database
work
is
like
well
defined,
unknown
in
advance,
we'll
try
and
ship
the
database
work
first,
get
it
into
the
review
process
as
early
as
possible.
But
you
can't
always
do
that
because
you
know
the
database
works
informed
by
the
you
know.
E
So
the
things
we've
done
on
our
end
to
try
and
mitigate
the
fact
that
it
takes
longer.
We
also
like
I
believe
how
it
like.
We
have
quite
a
few
people
in
training.
I,
don't
know
how
many
I
haven't
seen
the
I
haven't,
seen
the
list
of
issues,
but
yeah
I,
don't
know
of
any
process
other
than
simply
tagging
somebody
else
if
you're
really
eager
to
get
it
through
in
one
person's.
You
know
slammed
with
release
today.
A
E
It
is
it's
one
of
the
three
backend
kpi's
yeah.
It's
called
mean
time
to
merge,
but
there
can
be
like
multiple
reasons
why
that
would
go
up
or
down
like
like
database
review.
Being
involved
is
definitely
I.
Would
imagine
like
one
of
the
big
factors,
but
then
the
number
of
the
number
of
this
different
disciplines
involved
in
the
EM
are
like.
E
So
if
there's
documentation
or
some
front-end
work
and
some
back-end
work
inside
of
this
work,
could
like
it's
gonna,
be
that's
gonna,
be
the
main
contributing
factor
to
how
long
it
takes
how
complex
the
work
is.
How
many
like
how
well
defined
it
is
in
advance
of
actually
being
done,
and
we
definitely
want
to
try
to
make
sure
that
things
are
better
defined
like
before
we
start
working
on
them.
E
There's
been
a
couple
of
things
we
can't
think
of
any
off
the
top
of
my
head,
but
I
could
go
digging
where
the
Ammar
has
become
has
stayed
and
in
progress
for
a
long
time,
and
conversation
has
happened
on
the
mr
about.
What's
the
best
way
to
actually
implement
the
thing
and,
like
that's
probably
better
done,
jerem
plan
and
break
down?
E
Honestly,
I
think
it's
literally
a
subtraction
of
the
time
that
mr
was
created
from
the
time
the
mi
was
merged.
That's
what
that's
why
I
think
like?
If
you
have
very
occasionally,
we
have
very,
very
long
running
Amar's,
which
maybe
the
work
was
started,
but
it
wasn't
necessary
at
that
time
and
it
gets
put
on
the
back
burner
and
I.
Think
like
the
person
that
picks
that
up
you
know
a
couple
of
months
later
works
on
it
and
immediately
it
pops
up
and
figures
like
you
know,
this
took
three
months.
E
A
E
A
E
E
Thing
we
also
have
a
universal,
so
called
universal
engineering
team
KPI
board
on
periscope,
which
you
might
find
interesting,
so
I'll
put
that
nd
in
the
agenda.
It
has
our
mr
break
funds
by
category.
It
has
our
mean
time
to
merge
and
our
throughput.
So
it's
typically
interesting
for
engineering
lungers.
I
guess,
but
might
be
interesting
to
other
people
as
well.
A
D
So
so
this
is
the
purpose
of
it
to
to
teach
you
my
name:
I'm
Martin,
like
chin
and
even
though
I
introduced
myself
in
the
slack
channel
with
Russell
I.
Think
me
as
well.
You
know
I
wanted
to
use
this
opportunity
that
I'm
here,
looking
at
your
face,
sly
for
the
first
time
so
yeah
I'm
gonna,
be
for
12.8
I'm
gonna,
be
the
training
tech
writer
being
so
high.
D
B
Comment:
I
can
unmute
fast
enough
when
we're
doing
our
we're
doing
like
retro
pros
at
the
end
of
our
cycles.
Can
we
are?
Are
we
flagging,
like
hey
I'm,
stuck
in
database
review
or
this
area
for
each
issue,
or
is
that
something
we
could
do
just
to
grab
some
some
info
per
cycle
until
we
have
somewhere
like
actual
analytics.
A
It
might
be
helpful,
I,
don't
know
actually
I,
don't
know
what
would
it
be
helpful
to
have
that
information
may
be
in
our
retro
like
once?
Something
is
delivered
start
talking
through.
You
know
what
essentially
you
having
a
retro
on
a
single
issue,
or
maybe
we
should
continue
having
the
one-off,
retros
I.
Don't
know
what
do
y'all
think.