►
From YouTube: Plan stage weekly meeting 2019-10-23
A
Hey
this
is
the
plan
stage
weekly
meeting
for
23rd
of
October
2019
I'm
gonna
start
off
with
the
team
update
section
didn't
really
know
if
this
was
a
team
update
or
something
else,
but
I
thought
I
put
it
here,
Heinrich's
now,
back-end
maintainer,
so
you'll
be
reviewing
and
merging
a
much
more
MS
and
congratulations
to
Heinrich
he's
done
a
great
job.
There
Katherine's
got
something
in
the
big
picture
updates
which
is
read-only.
A
A
A
So
please
take
a
look
at
that
epic,
yeah
I
added
a
point
about
the
dev
section
strategy
review,
so
the
dev
section
being
plan
manage
and
creates
that
Eric
Brinkman
run
yesterday,
Gabe,
Keenan
or
mark
did
any
of
you
want
to
talk
through
that
at
all
I've
linked
to
the
video
and
their
questions,
doc
and
the
actual
page
in
the
handbook.
But
I
don't
know
how
much
you
wanted
to
talk
around,
like
maybe
the
plan
part
of
that
strategy.
C
Let
me
share
my
screen
right,
quick,
there's
a
chance
that
it
will
tank
and
mice
anymore
freeze,
but
that
happens,
I'll
be
back
and
you
guys
can
continue
on
all
right
cool.
You
should
be
able
to
see
my
screen
at
this
point,
so
this
is
it
about
back
at
the
lab
comm
slash
direction,
slash
dev
what
I
guess
the
major
changes
that
we've
deprecated
the
idea
of
a
stage
level
vision
page
so
like.
C
If
you
go
to
direction
and
slash
plan,
it
will
redirect
it
dev,
but
we're
still
maintaining
the
category
level
strategies,
and
so
the
general
goal
for
this
is
just
to
make
sure
that,
like
as
we
grow
and
as
we
get
bigger,
we
maintain
alignment
across
stages
and
then
also
within
the
same
stage.
So
hence
rolling
up
to
like
a
section
level
kind
of
strategy
and
vision.
C
There's
also
the
shift
that
we're
trying
to
move
towards
having
a
one
year
kind
of
roadmap,
I
guess
which
we're
considering
a
one
year
plan
and
then
a
three
year
strategy
and
then
a
10-year
vision,
I
think
that's
what
it
says
in
the
handbook.
So
this
is
the
first
like
kind
of
like
iteration,
on
rolling
all
that
stuff
up
with
the
higher
levels.
So
there's
a
couple
of
themes
which
you
can
look
at
and
I'll
just
like
kind
of
run
through
these
pretty
quick.
C
Some
of
them
have
to
plan
some,
don't
but
kind
of
improving
coded
review,
increased
efficiency,
the
value
stream,
which
is
something
that
analytics,
is
working
on
within
the
manage
group
or
manage
stage
devops
for
more
personas.
This
is
kind
of
applies
to
us
where
we're
trying
to
were
already
loved
by
a
lot
of
engineers,
but
we're
trying
to
become
loved
by
other
roles
like
park,
managers
and
designers,
for
example.
So
another
theme
is
enterprise,
digital
transformation.
C
This
is
like
you
know,
I
think
a
big
kind
of
thing,
but
it's
it's
really
relevant
to
organizations
that
aren't
using
devops
when
I
was
at
cab
last
week.
There's
a
lot
of
our
customers
who
have
a
small
segment
of
their
organs
using
gitlab
and
continuous
integration
and
those
sorts
of
things,
but
they're
championing
it
within
the
organization.
So
it's
definitely
like
trying
to
help
it
spread
across
the
entire
company
and
not
just
like
in
a
subset
of
it,
which
is
kind
of
how
it
is
right
now
for
a
lot
of
our
customers.
C
This
one
definitely
applies
to
us
project
management,
Morstan,
product
management
and
I.
Think
this
is
where
this
is
a
shift
in
a
lot
of
organizations
that
are
struggling
with
it.
When
I
was
on
site
with
a
customer,
they
lamented
that
they
had
made
this
transition,
but
really
all
they
did
was
change
everybody
style
from
project
manager
to
Prok
manager
and
they
didn't
change
any
of
their
processes
and
that
the
the
point
of
this
is
instead
of
delivering.
C
Like
a
time
in
box,
we
have
a
fixed
set
of
scope
and
requirements
and
we're
gonna
get
delivered
on
time.
Budget
organization
just
urge
evolving
into
looking
at
the
lifecycle
of
a
product
or
a
thing
that
they're
working
on
not
just
like
how
do
we
get
launched.
But
what
happens
after
it
launches?
How
do
we
grow
it?
How
do
we
nurture
it?
Are
we
delivering
business
value
and
are
we
delivering
customer
value
and
kind
of
looking
at
the
bigger
picture
and
I
think
that's
the
heart
of
this
kind
of
theme
in
terms
of
one-year
plans.
C
This
is
where
I
think
we're
gonna
invest
a
lot
on
our
Kanban
boards.
I
would
like
to
propose
changing
as
two
boards
at
some
point
in
the
future,
as
we
integrate
things
like
epics
and
maybe
other
entities
within
gitlab
into
the
boards
is
like.
Even
those
visibility
issue.
Boards
and
Kanban
board
seems
a
little
bit
too
like
pigeon-holed,
but
I'll
bring
that
up
separately.
We
really
want
to
do
things
like
making
it
first,
real-time
and
making
it
more
collaborative
for
team
members
where
everybody
can
work
around
the
same
kind
of
issue
board.
C
C
Another
big
goal
is
to
make
it
so
that
we
can
import
customers
from
Fira
without
losing
required
data,
so
something
that
I'll
probably
be
working
on
manage
as
well,
because
they
have
an
importer
group
and
they're
going
to
be
working
on
that
and
then
we're
gonna
invest
a
lot
in
an
enhancing
portfolio
and
project
roadmaps,
so
building
a
better
Road
mapping
tool.
This
is
gonna,
involve
kind
of
epics
and
I
know.
C
Keene
is
working
a
lot
on
this
stuff
right
now,
which
will
also
enable
easier
top-down
planning
and,
as
part
of
this
kind
of
exposing
better
reporting
analytics.
So
answering
questions
like
are
we
gonna
get
done
on
time?
How
much
is
this
costing
us?
What's?
The
scope
of
this
has
a
scope.
Changed
is
my
team
half
capacity.
C
So
a
requirement
is
like
an
expected
behavior
of
a
system,
but
that's
also
the
same
thing
as
like
a
feature
right.
A
feature
should
behave
a
certain
way
and
it's
gonna
live
longer
than
an
issue
like
an
issue
might
implement
a
requirement,
but
then
the
requirement
stays
around
longer
than
that
because
it's
part
of
the
core
product,
and
so
what
does
that
look
like?
And
how
does
that
play
into
kind
of
the
idea
of
transitioning
from
project
product
I?
C
C
I
think
that
is
on
our
handbook
page,
the
links
to
like
the
overall
plan
roadmap
stage
level
metrics
you
can
find
here
in
the
dashboard
it's
in
periscope
and
then
the
definitions
are
on
our
handbook
page
and
then
you
can
click
through
to
each
of
these
strategies,
for
the
different
categories.
I
will
be
updating
these
some
I
did
go
through
and
update
these
like
at
least
my
three
within
the
project
management
group.
So
it's
worth
reading
through
them
because
it
does
it's
like
it's
not.
C
What
was
here
a
couple
of
months
ago
and
I'm
gonna
try
to
these
again
and
probably
run
through
the
category
specific
strategies
with
the
team
next
week.
If
that
works,
but
I
want
to
throw
us
off
today,
does
anybody
have
any
questions
about
high
level
vision
plan
strategy
concerns?
Any
discussion
points.
C
C
A
And
similarly
does
it
have
a
group
label.
Like
you
know,
if
it's
been
developed
plan,
that's
fine,
but
you
know.
If
people
are
looking
at
the
project
management
group
label
or
the
portfolio
management
group
label
of
a
certified
group
label,
they
won't
see
something,
that's
missing
any
of
those
and
then
a
couple
of
other.
A
What's
the
word,
it's
kind
of
just
mirroring
the
actual,
like
you
know,
native
blocking
issue
state
so
yeah.
Basically,
the
form
this
is
going
to
take
is
that
yemm's
and
possibly
PM's
will
get
pinged
on
automatically
created
issues
every
so
often
to
do
these
tasks.
I,
don't
think
we
need
meetings
to
do
these
tasks.
We
just
need
to
you
know,
have
a
have,
an
item
that
creates
a
to
do
and
get
lab
and
things
everybody
who
needs
to
work
on
that
and
then
the
year
through
it
so
yeah,
basically
mostly
interesting
to
me.
B
D
This
yeah
I'm
sure
can
covert
like
their
dashboards
that
show
our
KPIs
or
the
KPIs
were
measured
against
so
throughput,
mainly
as
throughput
over
time
and
there's
one
for
portfolio
management
and
certifies
back-end
team
and
one
for
project
management's,
back-end,
team
and
I.
Think
Donald's
has
there
that
he
has
one
in
progress
as
well
and
they
don't
include
security
em
ours
in
the
kind
at
the
minute,
so
the
numbers
at
least
somewhat
dine
on
what
they
actually
are.
A
Month,
but
just
to
be
clear,
like
the
performance
indicators
like
at
the
development
level
like
we're,
creating
these
team
dashboards,
just
because
it's
useful
for
us
to
know
as
managers,
but
the
performance
indicator
isn't
at
the
individual
level.
We're
not
saying
each
individual
person
needs
to
do
this
in
every
single
month
or
whatever.
Like.
That's,
that's,
not
the
goal
here.
We
recognize
it
as
variability
and
yeah
we're
not
really
interested
in
looking
at
this
on
a
person-by-person
basis.
Is
it's
more
about,
like
you
know,
it's
the
team,
health?
Okay.
A
According
to
this
performance
indicator
on
the
security
issues,
actually
I
think
I
saw
somewhere
that
we're
gonna
move
development
of
security
issues
to
get
lab
comm
at
some
point,
soon,
ish.
So
hopefully,
once
that
happens,
then
that
gets
included
in
this
data
for
free.
Otherwise,
we
haven't
liked
to
go
and
update
our
dashboards
I.
B
C
A
A
So,
from
my
perspective-
and
this
is
just
me
talking-
I-
don't
have
any
special
inside
knowledge
here.
I
see
this
as
like.
A
staging
performance
indicator
where,
like
once,
we
get
the
health
of
this
performance
indicates
like
sorry,
not
the
health.
Once
we
keep
hearing
this
performance
indicator,
we
then
like
start
to
refine
it
and
make
it
more
directly
related
to
those
goals
that
we
have
as
a
company.
But
this
is
like
a
simple
thing
to
measure
that
we
should
be
able
to
like
accomplish
as
a
performance
indicator
on
the
way
to
that
point.
A
C
That
makes
sense
one
of
the
things
that
I've
done
historically
and
it's
worked
well,
is
not
weighted
and
like
not
added
weights
to
defects
and
not
added
weights
to
things
that
didn't
add
customer
value
in
some
way
from
like
an
issue
standpoint
right.
So
if
you
have
a
much
defects
and
I
know,
it's
like
would
produce
a
little
bit
of
challenge
from
a
capacity
playing
standpoint,
but
the
weight
kind
of
equals.
C
The
amount
of
value
shipped
so
by
using
that
kind
of
is
a
way
to
indicate
that
it's
easy
to
differentiate
between
those
issues
that
are
just
like
I'm
fixing
a
defect
or
I'm,
paying
down
some
technical
debt
that
you
know
we
accrued,
which
is
not
technically
customer
value
and
just
being
able
to
differentiate
those
issues
in
some
way
or
another.
That
way,
you
can
look
at
throughput
that
way
from
like
weight
delivered
or
some
other
metric
delivered,
but
that's
just
something
to
think
about.
As
we
kind
of
evolved.
This
yeah.
E
A
I
think
I
definitely
read
the
idea
before
that
bugs
are
essentially
all
the
same
weights,
because
it's
not
just
for
a
customer
value
perspective
but
from
like
a
you
know,
project
management
perspective,
like
a
lot
of
the
time
by
the
time
you've
waited
the
bug,
you've
kind
of
figured
out
how
to
solve
the
bug.
So
you
better
off
just
like
assuming
they're
all
the
same
weight
and
then,
like
you,
know,
deferring
the
actual
like
investigation
until
you
dive
into
fix
it.
A
There
will
be
some
that
blow
up
but
like
normally
you
can
decompose
those,
but
most
of
the
time
it's
like
if
you've
investigated
enough
to
give
it
a
really
confident
weight.
You
probably
already
know
how
to
fix
it
and
then,
like
you
know,
the
rest
is
just
typing
pretty
much
so
yeah
I
think
there's
definite
value
in
that
courage.
A
D
D
I
mean
like
I,
know
it's
it's
not
a
perfect
metric,
but
I.
Think
if
there's
one
thing,
that's
positive
about
about
it,
it's
that
it's
blunt
and
it's
bluntness
is
obvious,
and
so
you
know,
and
then,
if
you
look
at
some
of
the
immediate
alternatives
like
measuring
waste,
that
tends
to
put
upward
pressure
on
estimations,
whereas
measuring
the
number
of
mrs
actually
puts
downward
pressure
on
issue
complexity,
because
people
are
encouraged
to
break
issues
up
into
smaller
pieces
and
do
them
in
smaller,
increments
I.
D
D
A
Generates
eight
for
now,
because
we
haven't
got
four
releases
away
from
the
single
codebase:
that's
like
the
trick
there,
but
yeah.
I
think.
Actually,
the
the
target
is
now
eight,
mrs
per
engineer
per
month,
because
of
the
move
to
a
single
code
base
as
well.
I
should
I'm
sure
I
saw
that
somewhere,
so
yea.
F
I
feel
like
there
were
also
issues
like
when
I
first
started
around
like
when
we
started
really
using
throughput
as
the
KPI
around.
What
we
want
to
measure
like.
Does
it
make
sense
to
use
m
RS
or
do
we
want
to
track
it
either
the
issue
level
or
a
weight
level?
I,
don't
know
if
that's
just
an
open
issue,
I
think
Dahlia
was
leading
that
back.
Then
you
remember
that
Shauna
well,
I,
don't
know
if
anyone
else
was
yeah.
F
F
C
Is
also
kind
of
important,
so
we're
gonna
be
building
this
into
the
product
and
then
like
next
few
months.
So
it's
like
a
big
thing
like
basically
like
are
we
gonna?
Get
done
on
time
is
the
question
that
a
lot
of
customers
are
asking
and
I
think
we
asked
to
so
it's
it's
good
for
us
to
be
involved
in
the
conversation,
as
it
will
also
shape
how
the
product
involves
I.
Think
over
the
coming
releases,
I
encourage
everybody,
participate.
D
Like
the
next
item
yeah,
this
is
just
something
we
noticed
during
the
week.
I
mean
that
if
you'd
use
like
different
boards
to
prioritize
issues
in
a
column
or
in
a
and
under
a
label
like
ready
for
development,
that
they
wouldn't
just
move
in
another
board,
which
you
would
expect,
but
they
jump
around
in
in
the
main,
Kanban
board
and
I-
think
it's
possibly
because,
like
the
numbers
used
for
sort
ability
or
like
vastly
different
for
different
boards
or
for
different
contexts,
I
don't
know
Shawn.
D
C
Is
is
relatively
ordered
or
sorted,
I
guess
across
like
like
globally,
so
you
could
go.
Do
that
an
issue
list
as
well
like
where
you
search
and
filter
issues,
and
it
would
impact
anything
that
happens
on
the
board
as
well
when
you're
manually
swimming
sure
thing
is
like
great,
sometimes
and
really
bad
others,
not
self.
D
A
Yeah
I
think
I,
don't
maybe
I'm
wrong
here,
but
I
feel
like
if
you're
moving
something
into
in
dev.
It
doesn't
matter
too
much
because
like
at
that
point,
the
priority
is
like
you're
moving
into
indent
because
you
were
assigned
to
it
right
like
so
like
that's
like
the
priority,
is
that's
actually
being
worked
on,
I
think
it's
more
important
in
the
the
left-hand
columns
like
getting
up
to
ready
to
development
through
scheduling
and
planning
breakdown
and
stuff
like
that,
because
that's
the
point
at
which
people
will
actually
see
things
in
that
order.