►
From YouTube: Plan stage weekly 2020-07-22
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).
B
Cool
yeah,
so
I'm
gonna
share
my
screen.
Real
quick
and
I
updated
my
category
direction
pages
and
I
just
thought
it
would
be
worthwhile
to
share
that
with
the
team,
just
the
things
that
are
like
different
new,
whatever
so
issue
tracking.
I
think
one
of
the
things
that
we
I
did
is
I
simplified
thanks
to
marcin
and
mike
long
for
contributing
simplifying
the.
B
I
guess,
the
purpose,
the
essential
intent
for
issue
tracking
to
provide
a
single
source
of
truth
from
an
idea
to
from
inception
to
implementation.
Members
of
community
should
be
able
to
trust
and
effectively
collaborate
on
it
from
anywhere
within
gitlab,
without
slowing
down
their
current
flow.
So
I
think,
like
this
is
a
little
bit
simplified
there,
but
I
guess
the
the
main
things
to
go.
Is
I
updated
this?
B
What's
next
to
y
section,
with
kind
of
like
the
outcome
of
the
major
thing,
themes
that
we're
gonna
be
tackling
over
the
next
several
months
and
the
outcomes
we're
hoping
to
achieve
with
them
for
our
customers
and
then
also
some
some
basic
progress,
because
we
can
jump
around
from
some
of
these
different
themes
from
time
to
time
and
the
one
that
I
added
that
wasn't
here
before
was
accessible
issues
and
issue
types.
So
there's
not
a
lot
that
we're
doing
right
like
in
13.3
for
this.
B
It's
mostly
like
thinking
and
planning,
because
the
monitor
health
team
is
using
issues
for
incidents
and
they
need
to
customize
them
and
so
we're
starting
to
think
through
what
it
looks
like
to
have
issue
types
behind
the
scenes
for
now,
but
eventually
user
facing.
So
they
can
configure
those.
And
let's
see
here-
I
did
go
down
and
I'll
soon
update
some
of
the
top
user
issues,
and
I
just
wanted
to
highlight
some
things
like
I've
been
keeping
like
these
counters.
B
So,
each
time
I
update
the
maturity
page,
I
can
track
the
velocity
basically
of
thumbs
up
to
see
which
things
are
training
and
which
ones
are
still
really
relevant
to
the
water
community.
So
one
of
them
that
is
still
like
kind
of
pretty
steady.
Is
this
a
list
of
all
subscribed
issues?
I
know
alexander
is
doing
some
work
there
to
to
get
some
migrations
in
place,
so
he
could
eventually
get
get
that
done.
B
The
one
that
had
the
biggest
jump
was
this
group
level
description
templates
for
issues
and
merge
requests,
so
it
had
a
jump
of
32
upvotes,
which
was
huge
and
basically,
this
is
like.
I
want
to
have
epic
descriptions
and
issue
descriptions
of
the
group
level
that
all
projects
within
that
group
can
access.
B
So
if
I
have
100
projects,
I
don't
have
to
maintain
100
different
templates
in
each
of
my
projects
and
then
the
other
ones
that
kind
of
steadily
gaining
traction
was
removing
the
list
label
and
closing
an
issue
and
there's
a
there's,
a
small
proposal
there.
B
So
I've
painted
a
couple
folks
on
this
just
to
ask
about
feasibility
for
some
of
these
things
that
are
smaller
and
maybe
we
can
try
to
get
them
into
13.4
and
then
I
think
I
updated
the
strategy
as
well
to
kind
of
show
basically
we're
working
towards
simplifying
groups
and
projects
in
that
working
group,
which
could
mean
consolidating
groups
of
projects
into
one
thing
and
then
having
like
the
inheritance
behavior.
B
It's
pretty
interesting
problem
to
solve,
but
it's
kind
of
really
important
for
the
plants
age
in
particular,
because
planning
is
cumbersome
when
you
have
ethics
at
a
group
level,
one
issues
at
a
project
level
and
all
that
other
stuff.
So
that's
that
is
issue
tracking
and
I
think
let
me
go
down
to
the
jira
importer.
I'm
not
gonna
run
through
it,
but
what
I
basically
did
is
I
updated
the
very
bottom.
B
I
think
it's
worthwhile
to
work
towards
merging
the
work
we've
done
with
the
importer
with
the
jira
integration,
so
the
integration
team's
taking
some
time
off
we're
taking
some
time
off
from
the
importer,
but
to
come
up
with
a
kind
of
more
formal
plan,
but
I
think
ultimately
it
makes
sense
to
merge
those
two
things
together
and
then
the
other
one
that
I'll
kind
of
spend
a
little
bit
time
covering
is.
B
I
went
through
the
kanban
boards
direction
page
and
I
updated
it
to
sort
of
be
more
generic
and
remove
references
to
just
issue
boards,
so
keenan,
I
think
he's
going
to
be
driving
boards
for
a
little
bit,
especially
as
he's
working
on
programming
boards,
our
epic
boards
and
the
swimlane
stuff,
and
we're
going
to
be
collaborating,
of
course,
but
boards
are
need
to
evolve
to
support
more
objects.
B
They're
not
just
issue
boards
anymore,
and
I
think
like
using
them
for
issues
is
one
use
case,
but
as
we
have
epic
swim
lanes
and
as
we
have
epic
boards,
there's
also
an
ask
to
have
merge,
request
boards
right
and
boards
for
different
object
types
and
how
that
behaves.
B
I
think
boards
are
going
to
evolve
a
little
bit
outside
of
just
issues,
so,
in
addition
to
making
real
time,
we
want
to
make
them
kind
of
more
extensible,
which
is
a
general
theme,
and
so
I
updated
the
strategy
down
here
to
kind
of
reflect,
reflect
those
sort
of
goals
and
yeah.
So
that's
a
general
update
about
direction
pages
that
I
did
this
month
and
just
wanted
to
keep
everybody
in
the.
B
A
All
right,
we'll
move
on
to
demos,
then
kashal
you're
up
first.
C
Yep
so
sharing
my
screen,
so
we
have
been
planning
to
work
on
making
asynchronous
filtering
support
in
roadmap
by
making
use
of
some
framework
features
that
we
have
introduced
in
past
couple
of
months.
One
prominently
being
this
filtered
search
component,
which
is
now
part
of
gitlab
ui,
so
that
allows
us
to
make
asynchronous
search.
C
So
today,
if
you
go
to
gitlab.com
in
any
group
and
search
for
something
you
would
have
to
hit
enter,
and
it
would
reload
the
whole
page
with
the
filters
of
flight,
you
don't
want
that
because
the
roadmap
is
loaded
asynchronously,
so
filtering
should
also
work
asynchronously.
So
that's
the
goal
here
so
visually.
It
shouldn't
look
much
different
from
what
we
have
now,
except
for
some
behavioral
changes.
So
we'll
start
with
the
these
three
sections
or
layouts
that
we
support.
So
these
three
layout
switching
action
will
still
be
asynchronous
because
right.
B
C
Roadmap,
app
once
gets
loaded
needs
to
calculate
bunch
of
layout
stuff,
like
screen
width,
column,
size
and
the
number
of
months
that
we
want
to
show
on
initial
load.
So
those
actions
require
some
initial
computation,
so
at
least
for
first
situation,
we
will
have
these
three
buttons
behave
asynchronously,
so
switching
between
these
should
still
reload
the
page,
but
from
there
onwards
everything
is
asynchronous,
so
we
start
with
the
epic
state
drop
down.
C
Immediately
then,
the
next
one
is
obviously
filtered
search
bar,
so
we
are
starting
with
having
a
the
search,
both
in
label
filtering
will.
B
C
Same
thing
goes
for
labels,
so
if
I
just
select
one
of
the
labels
hit
enter,
it
will
match
with
the
criteria
that
was
selected
and
obviously
plain
text
search.
So
if
I
search
like
test
which
does
not
exist
either
in
the
title
of
this
epic
or
the
description,
so
if
I
hit
enter
it
will
not
match
anything.
C
But
if
I
just
remove
the
plain
text
hit
enter
again,
it
will
bring
up
the
results
and
if
I
clear
the
filter,
it
will
clear
all
the
filters
and
load
the
resulting
synchronously
same
thing
goes
for
sorting
as
well
like.
If
I
select
date,
then
it
would
basically
sort
by
the
dates
and
if
I
change
the
direction
it
will
do
that
asynchronously
as
well.
S3
is
also
available,
like
all
my
recent
five
searches
are
available
there.
So
if
I
select
one
of
the
existing
search.
C
Like
we
had,
except
for
the
full
page
reload
part,
obviously
we
still
plan
to
add
milestone
filtering,
but
that
is
for
another,
mr,
where
we
need
to
have
back-end
support
in
the
graph
query
to
begin
filtering
based
on
milestones,
but
so
far
this
is
the
progress
and
as
we
move
on
to
other
places
where
we
want
to
have
asynchronous
filtering
functionality,
all
the
framework
level
changes
that
we
are
doing
for
roadmap
should
be
reusable
in
other
places
as
well.
So
that
was
it
any
questions
or
feedback.
C
You
might
have
feel
free
to
reach
out
or
post
it
in
client
channel
thanks,
that's
great
kush
off
thank
next
is
alex.
D
Right
he
dropped
off.
His
net
was
having
some
difficulties.
He
just
mentioned
that
we
should
probably
align
the
name
of
the
iterations
table
and
the
database
is
sprints
from
when
it
was
named.
That
the
feature
was
named
that
so
now
that
we've
launched
that
we
may
want
to
migrate
that
to
just
call
it
sprints
or
sorry
call
sprint's
table
iterations,
which
I
think
is
probably
the
right
move
and
probably
good
to
do
before
a
bunch
of
people
start
using
that
feature
in
that
table
grows
and
then.
D
D
So
part
of
the
goals
for
thirteen
three
are
having
the
burn
up
and
burn
down
charts
on
the
iteration
report
as
well
as
kind
of
like
finalizing
them
on
the
milestone
report,
because
they've
been
sort
of
in
a
half
done
bit
of
a
wonky
state
on
the
milestone
pages.
So
in
13.2
we
shipped
the
data
events
on
by
default
for
everything
around
milestones,
but
we
don't
yet
have
those
four
iterations.
So
that
means,
when
you
know,
issues
that
are
in
iteration
are
closed
or
moved
out
of
the
iteration.
D
It
creates
a
an
event
that
tracks
like
what
happened
there,
so
you
can
keep
track
of
the
scope
within
an
iteration
which
is
necessary
data
for
those
charts.
So
what
we're
trying
to
do
in
133
and
like
this
is
probably
going
to
come
in
a
little
tight
is
introduce
those
endpoints
to
introduce
that
data
for
the
front
end
and
then
also
have
the
front
end
build
out
those
charts
and
heinrich's
working
on
that
now
so
there's
a
chance.
D
We
get
it
done
early
in
the
early
enough
in
the
iteration
that
we
can
also
get
the
charts,
get
the
charts
going.
But
I
think
alex
was
just
calling
out
that
kind
of
disparity
between
don't
have
that
you
don't
yet
have
the
data
trying
to
deliver
the
charts
by
the
end
of
the
iteration
or
by
the
end
of
the
milestone.
You
know
it's
a
little
bit
of
a
chicken
and
egg
problem.
D
I
don't
game
if
you
wanted
to
expand
on
what
you
said
there
about
the
charts
being
decoupled.
B
Oh
yeah
sure,
so
I
think
the
the
burn
down
and
burn
up
charts
are
like
on
the
or
stepping
back.
The
way
I've
been
thinking
about
it
is
the
milestone
report
is
not
in
view,
and
the
iteration
report
is,
and
once
we
have
at
the
group
by
functionality
it
will.
It
will
be
we'll
have
feature
compatibility
with
the
existing
milestone
view,
so
we
won't
be
removing
anything,
and
so
we
can
basically
reuse
the
iteration
report
for
the
milestone
report
and
I
think
the
mechanics
are
pretty
much
exactly
the
same.
B
But
one
of
the
things
that
we
also
want
to
do
is
put
like
burn
down,
charts
and
burn
up
charts
and
some
other
metrics
eventually
like
in
some
part
of
a
board
or
expose
them
on
a
board.
That's
we've
gotten
from
the
analysts
that
we
first
support
for
single
scrum
teams
within
boards,
because
we
don't
also
have
analytics
in
the
boards
right
where
the
teams
do
the
planning,
so
we're
gonna
have
to
figure
out
how
to
solve.
B
For
that
at
some
point
and
then
there's
also
like
a
lot
of
requests
for
the
non-engineering
personas
when
they
log
into
gitlab.
They
don't
want
to
have
to
go
dig
for
their
burnout
chart.
They
just
want
to
be
it
like
on
their
homepage
or
their
group,
or
project
page
dashboard.
So
I
think,
there's
like
all
I'm
saying
is
that
it
will
be
reused.
Lots
of
places
so
like
we
should
build
it
in
a
traditional,
like
standalone
component
type
thing
so
that
it's
easy
to
plug
into
all
those
places.
E
E
Yeah,
I'm
not
sure
if
you
can
hear
me,
and
hopefully
I
don't
drop
off
while
talking
that
that's
that's
the
idea
actually
and
I
think
how
it
is
built
right
now
they
burn
down
and
burn
up
is
that
there
is
a
front-end
component
that
is
being
fed
with
some
back-end
data.
Well,
it's
an
array
of
data
grouped
by
the
by
dates.
E
So
the
thing
is,
then
you
build
that
back-end
data
and
feed
it
up
to
a
same
front-end
component
that
can
be
reused
in
different
places.
So
the
main
thing
is
like
building
that
back-end
data
array
of
data
that
you
need
to
build
the
chart
department.
B
Yeah
one
thing
that
I
think
I
mentioned
to
drake
too.
I
know
we
were
talking
about
right
now.
I
think
we
send
a
bunch
of
issue
data
to
the
front
end
and
the
front
in
that
array
and
then
the
front
end
parses
that
and
transforms
it
into
like
the
the
basically
time
series
plot
points,
and
so
we
were
talking
about
having
the
the
server
pre-calculate,
all
that
and
just
to
send
the
front
end
the
array
of
plot
points,
and,
if
that's
like,
I
agree
with
that
in
isolation.
B
I
agree
with
whatever
engineer
just
wants
to
do,
but
just
something
else
that
we're
looking
at
is
when
looking
at
iteration
report,
for
example-
and
we
have
the
group
by
or
the
ability
to,
filter
out
certain
things,
so
you
only
see
a
subset
of
the
information
and
when
we
do
filter
out,
like
maybe
some
of
the
issues
or
whatever,
we
would
want
the
the
charts
to
re
re-render
with
only
the
scope
that
is
filtered
down.
If
that
makes
sense.
B
So
I
don't
know
if
that
means
we
have
to
recalculate
everything
on
the
back
end,
I
guess
the
pros
and
cons.
Are
you
get
an
initial
huge
payload
from
the
back
end
the
front
and
has
to
do
all
the
work,
but
then,
whenever
the
filters
happen,
you
don't
have
to
make
another
back-end
request
anyway.
I'll
leave
it
to
you
all
to
make
the
trade-off,
but
just
so
you
do
have
more
context
for
making
the
decision.
I
thought
that
would
be.
E
Previously,
we
were
standing
all
of
the
back
end
data
like
whatever
we're
getting,
then
we're
sending
to
the
front,
and
I
think
now
we're
just
computing
everything
by
date.
So
the
amount
of
data
is
much
much
less,
obviously,
depending
on
the
milestone
range.
If
we
take
us
like
the
sprint
should
be
fairly
short,
like
two
weeks
or
three
weeks
or
whatever
the
well
the
day
iterations.
E
D
Right
and
so
gabe,
I
think
so
just
to
clarify
like
if
you're
looking,
let's
say,
you're
looking
at
the
iteration
report
and
it
has
a
burn
up
chart
of
the
iteration
so
issues
you
know,
issues
assigned
issues
completed,
are
kind
of
like
your
two
lines
and
then
you
can.
You
give
me
like
an
example
of
like
you're
filtering
down
by
something
and
then
the
chart
changes
sure.
B
B
We
want
to
see
our
burn
down
for
just
our
team,
we
would
go
in
and
we
would
we
would
group
by
label,
and
then
we
would
filter
the
group,
the
labels
that
are
there
to
just
show
group
colon
colon
project
management
or
devops
cold
colon
plan
right
and
so
that,
if
that
would
remove
everything
from
the
list,
basically
hide
it
and
then,
since
it
would
just
be
showing
our
our
groups
or
stages
issues,
I
would
want
the
burn
up
and
burn
down
charts
to
reflect
just
our
stages
issues.
D
Yeah,
I
can
try
to
do
that
too.
I
think
I
mean
there's
some
conversation
about
it.
We've
had
on
issues,
but
I'm
just
trying
to
trying
to
balance
the
concern
of
caching,
the
data
so
that
they
can,
like
the
charts,
can
be
very
quick
and
they're
not
like
with
how
we
so
yeah.
Maybe
it's
caching,
a
massive
data
set
and
then
the
front
end
handles
filtering
it
between
that
anyway,
we'll
figure
it
out.
A
Real
quick
just
to
clarify
on
that
so
for
13.3,
are
we
planning
on
keeping
it
the
same
way?
We
do
milestones
in
that
we're
sending
just
all
the
data
to
the
front
end
and
then
the
logic
to
render
the
chart
is
primarily
on
the
front
end
and
then
down
the
road.
We're
going
to
switch
that,
or
are
we
planning
on
changing
the
way,
we're
handling
that
in
133
for
iterations.
D
That
is
a
good
question.
I
the
my.
If
memory
serves
we're
going
to
treat
it,
the
way
milestones
are
treated
currently
and
then
change
it,
but
that
I
talked
to
heinrich
yesterday
and
now
I'm
kind
of
like
parsing
through
what
he
said
and
that
may
be
wrong.
So
I'll
follow
up
on
that
and
and
check
in
with
you.
B
A
Okay,
so
it
looks
like
next
is
workflow
I'll
just
go
through
the
goals
for
the
next
week
or
the
next
iteration
on
the
front-end
side
of
things.
A
I
couldn't
hear
that
I
was
gonna
move
these
over
to
iteration,
one
we'll
probably
still
do
that,
but
I'll
make
the
decision
after
gabe's
comment
be
there,
but
we
can
go
through
these
the
goals
before
we
decide
how
we're
going
to
handle
iterations
anyway,
so
far,
iterations
what
we
just
talked
about
the
charts,
the
burn
up,
burn
down,
charts
we're
working
on
the
burn
down
chart
initially,
but
then
the
burn
up
chart
shouldn't
it.
A
It's
just
a
matter
of
getting
the
the
right
data
in
also
including
the
report
page
within
projects
is
a
goal
for
the
for
the
next
week.
I
think
we're,
I
think,
there's
a
back.
That's
a
front
end
back
in
issue,
so
we'll
be
working
with
with
the
back
end
on
getting
that
on
getting
that
in
our
swim
lanes.
A
few
things
continue
integrating
issue
cards
with
the
back
end,
working
on
drag
and
drop.
A
There's
two
issues
for
drag
and
drop,
one
dragging
them
from
to
allow
for
different
epics
or
for
moving
to
different
epics
and
then
one
for
allowing
movement
to
different
issues
or
I'm
sorry
different
lists.
A
I
don't
know
which
one
we're
working
on
specifically
in
the
next
week,
but
it'll
definitely
still
be
it'll,
be
one
of
those
drag
and
drop
issues
and
then
integrating
with
a
mutation
on
the
back
end
on
the
sidebar
we're
working
on
creating
that
sidebar
container.
So
we
can
start
adding
the
graphqlfied
components
to
it
so
probably
container
in
the
following
week
and
then
components
after
that.
A
Lastly,
for
swim
lanes,
there's
a
couple
issues
about
moving
configuration
items
or
adding
configuration
items
to
boards
within
the
modal
I'll
be
working
on,
creating
that.
I
think
the
mr
for
toggling
labels
on
and
off
is
already
in
there
yeah,
the
mr
for
that
is
in
there
next
thing
is
adding
the
ability
to
hide
the
open
and
close
lists.
A
Our
requirements,
management.
There's
an
issue
out
there
for
right.
Now
we
do
in-line
creation
or
editing
of
requirements.
We're
gonna
move
that
over
to
the
right
sidebar,
which
is
pretty
cool.
I
know
gabe's
going
to
ask:
what
are
you
asking
gabe.
B
A
I
guess
there
is
no
requirement,
so
there
is
so
we
just
added
to
the
list.
It'll
be
interesting
because,
as
we
move
issues
to
so
right
now,
requirements
are
its
own.
It's
not
an
issue,
but
as
we
move
issues
over
to
a
single
single
view
app,
the
idea
is
that
we
can
have
like
the
issue
creation
issue
edit
in
places
in
a
lot
of
places.
A
So
in
the
sidebar
like
on
boards-
and
I
think,
there's
an
issue
up
there,
kushal
probably
has
a
link
to
that
on,
allowing
the
ability
to
create
or
edit
an
issue
within
the
I
think
it's
within
the
board
sidebar
so
be
interesting.
I
think
it's
a
good
one
to
start
on
having
the
ability
to
edit
everything
with
requirements
management
just
because
it's
a
bit
smaller
in
scope
but
yeah.
So
that's
what
there's
already
designs
within
that
issue.
That's
what
we're.
B
B
Probably
the
sidebar
might
need
to
be
a
little
bit
wider,
but
I
was
talking
to
holly
about
a
prototype
for
how
we
could
show
issues
in
every
context
right
so
in
the
list
in
a
board
wherever
the
same
thing
for
f.
Like
the
same,
I
think
we
should
work
towards
the
same
pattern
for
all
the
things.
So
it's
consistent,
but
I
think
that's
a
great
idea
because
it
doesn't
it
doesn't
like
kick
you
out
of
your
current
context,
which
I
love
so
kudos
for
moving
out
forward.
A
A
All
right,
moving
on
to
gabe's
question,
the
swim
lanes
have
enough
support.
A
I
believe
so
I
mean
on
the
front-end
side
next
week,
we'll
have
three
out
of
the
seven
or
eight
engineers.
What
do
you
think
on
the
back
inside
jake.
D
B
Well,
I
I
saw
one
thing
from
the
13-2
retro
one
of
the
back-end
engineers
just
mentioned
how
they
felt
a
little
overwhelmed
and
reached
out
to
others
for
help,
but
they
were
working
on
other
urgent
things.
So
I
guess
I
just
would
say
that
at
least
within
our
stage
we
should
support
that
effort
and
making
sure
it
hits
the
13-3,
and
I
don't
mind
if,
if
like
some
of
the
engineers
that
are
working
on
the
my
group
with
your
blessing
jake
support
them,
if
they
ask
for
help
so.
D
Oh
totally
yeah
for
sure
I
mean
we're
all
spread,
pretty
thin
and
all
kind
of
like
in
the
boat
together.
So
I
think
you.
D
To
make
the
scale
balance
out
wherever
possible
is
we're.
I'm
happy
to
you
know,
support
that
in
whatever
way
possible.
A
Cool
yeah,
I
mean
we're
all
under
this
understanding
that
that
swim
lanes
is
the
number
one
priority
within
the
within
the
stage.
A
B
Yeah,
so
I
think
we
opened
an
issue
to
talk
about
dog
fooding
it
a
little
bit
and
but
we
didn't
really
talk
about
specifically
how
or
like
the
mechanics
of
what
we
wanted
to
do,
and
I
I
noticed
this
from
another
team
who's
asking
questions
about
planning
and
not
just
iterations
but
doing
things
they
synchronously
and
in
a
synchronous
team.
B
We
would
have
like
a
30
minute
to
an
hour
like
iteration
playing
meeting
where
we
talk
about
like
we
look
at
the
board
and
we
talk
about
issues
and
weight
them
and
then
like
commit
to
them
and
put
them
into
the
iteration.
But
we
can't
really
do
that
necessarily
effectively
and
be
inclusive
of
everyone.
B
So
I
I
didn't
know
like
I
didn't
know
like
what
the
most
lightweight
thing
we
could
do
to
include
everybody
in
deciding
what
we
wanted
to
commit
to
for
a
duration
and
allow
them
all
to
participate
in
doing
that,
but
also
have
it
be
something
that
doesn't
drag
out
like
three
or
four
days,
because
iterations
are
supposed
to
be
like
only
a
week
long.
So
I'm
just
curious.
A
You
know
because,
similar
to
how
right
now,
when
we
do
release
planning
or
milestone
planning,
we
tend
to
we've
been
trying
to
start
like
a
like
a
month
beforehand,
which
may
be
too
long,
which
may
make
it
a
little
difficult
to
to
keep
on
top
of
everything
that
we
need
to
plan
for
a
milestone.
A
I
wonder
if
yeah
the
only
way
or
maybe
there
is
a
way
where
we
can
just
start
planning
a
couple
days
before
in
iteration
and
then
get
everything
figured
out
that
we
want
to
work
on
in
that
iteration
by
the
actual
start
of
the
iteration.
I
don't
know
what
do
you
all
think.
G
I
think
I
think,
a
key
part,
and
I'm
kind
of
just
speaking
at
this
from
the
portfolio
certified
side.
Since
that's
the
board
I
live
on
is,
I
think
we
need
to
find
a
way
to
get
the
items
in
planning
breakdown
given
like
an
early
weights
earlier,
because
then
that
allows
like
pms
to
kind
of
take
a
cross
cut
of
that
and
be
like.
Okay,
that's
there's
10
weight
here.
G
That
doesn't
seem
like
too
big
about
too
big
of
a
bite.
Okay,
these
are
the
ones
I
would
move
forward
given
given
bandwidth,
and
then
we
can
have
the
conversations
on
that's
too
much
or
we
have
room
for
more,
but
when
the
items
in
plain
breakdown
are
not
weighted,
it's
really
difficult,
at
least
for
me
to
say
this
is
what
I
think
we
can
get
done.
G
So,
if
we're
trying
to
do
smaller,
consumable
chunks-
and
this
is
something
charlie-
and
I
talked
about
in
our
shadowing
exercise
to
me-
it
feels
like
that's
the
area
where
we
get
hung
up.
Is
we
just
don't
even
have
a
curse,
very
idea
of
how
big
some
of
those
items
are,
and
so
it
makes
it
difficult
to
kind
of
say
here's
what
we
should
move
forward?
G
Doesn't
the
immediate
next
chunk
of
work,
so,
if
there's
way
a
way
for
us
to
weight
those
at
a
faster
cadence,
even
if
it's
only
a
couple
at
a
time
just
to
kind
of
paint
the
picture
of
how
big
the
work
might
be,
I
think
that
would
help
us
have
these
quicker
planning
conversations,
but.
A
Yeah,
that's
a
good,
that's
a
good
point
because
we're,
I
think,
where
we're
struggling,
we're
coming
to
a
stop
at
is
when
issues
are
in
planning
breakdown
and
there
are
large
issues
that
really
need
to
be
broken
down
into
smaller
issues,
because,
right
now
it's
in
plane
breakdown.
It's
a
single
issue.
Our
max
weight
is
essentially
a
three
that
we've
been
trying
to
keep
it
at.
A
So
I
think
we're
just
like
throwing
in
threes
when
we
really
should
be
broke,
breaking
them
down
into
other
issues,
but
then
it's
kind
of
hard
to
track
all
of
those
smaller
issues,
just
like
just
thinking
about
twin
lanes
where
we
had
an
epic,
but
it's
been
broken
down
into
a
lot
of
different
issues
like
I
had
trouble
tracking
where
every
issue
and
what's
currently
being
worked
on
at
so
I'm
wondering
I
mean
because
the
like.
Ideally,
we
still
want
to
get
to
an
issue
equals
in
iteration,
tops
right.
A
So
an
issue
essentially
has
the
from
start
to
finish,
can
be
done
within
a
week.
Is
that
still
what
we're
aiming
to
to
get
to.
B
Yeah,
I
I
think
something
should
be
able
to
get
started,
go
from
ready
to
development
and
verification
in
a
week,
and
some
of
that
is
going
to
be
outside
of
our
control
at
first,
like
we
can't
always
control
review
times
and
stuff,
but
it's
a
good
signal
to
help
like
service
that
and
get
support
outside
of
our
stage
to
improve
processes.
You
know
so.
A
Yeah
so
then,
I
wonder
if,
when
we're
going
in
and
weighing
like,
when
something
is
a
planning
breakdown,
instead
of
attempting
to
go
in
and
weigh
something,
we
have
dris
go
in
and
break
it
down
into
week-long
chunks
of
work.
A
And
then
I
mean
we
could
still
use
weights,
but
we'd
primarily
just
use
three
two
or
one
three
being
a
weak,
two
being
less
and
then
one
being
just
something
that
can
be
done
within
a
couple
hours
or
a
few
hours.
I
don't
know
if
that'll
help
anything.
G
B
Alex
had
a
good
idea
or
alexandria
he's
like
I'll
voice
it
for
him,
but
he
basically
said:
would
it
make
sense
instead
of
pushing
issues
into
an
iteration?
Let
team
members
pull
an
issue
from
the
milestone
into
a
given
iteration
await
it
when
moved
to
given
iteration,
and
I
think
that's
that's
traditionally
how
I've
always
done.
Iteration
planning
is
like
you
have
release
planning
where
you
have
like
a
high
level
like
t-shirt.
B
Size
type
thing
like
this
is
an
xxxl
or
whatever,
but
then
like,
as
you
break,
that
down
into
smaller
job
stories.
Those
job
stories
get
split
out
and
then
pulled
into
an
iteration
by
team,
and
when
that
happens
is
when
they
like
will
wait
something.
B
So
we
might
not
know
like
what
the
size
is
for
a
giant,
long
running
thing,
and
we
can
figure
out
like
a
maybe
a
different
waiting
skill
for
that,
like
a
t-shirt,
size
type
thing
for
an
epic,
almost
right
is
kind
of
where
I
want
to
know
like
how
big
is
an
epic
and
then
then
you
can
break
the
issues
down
into
smaller
pieces
that
can
get
pulled
and
waited
like
on
the
fly
that
that
gives
the
team
feedback
on
estimations
and
also
helps
estimates
not
be
stale
by
the
time
you
get
to
something.
A
Okay,
so
then,
when
it
is
in
epic
form
before
so,
when
it's
in
plant
breakdown
before
it
gets
to
ready
for
dev
or
before
it
gets
to
a
point
where
someone
an
engineer
can
pull
it
into
an
iteration,
then
we
just
have
a
really
high
level
swag,
essentially
that
or
t-shirt
size,
as
opposed
to
trying
to
get
it
down
to
a
one
two
or
three.
At
that
point,.
B
I
think
that's
one
of
the
things
that
I
I
put
in
the
13.2
retro
that
it
would
be
helpful
for
me
is
like
when
you
have
a
big
issue
like
that
thinking
about,
I
don't
care
as
much
about
all
the
details
for
how
we're
solving
it,
but
knowing
how
how
many
issues
it
should
be
spread
across
and
then
like
how
many,
mrs
for
each
issue
right
because
then
I
can.
I
can
essentially
track
the
overall
progress
of
something
of
something
like
I
know.
B
A
There
was
a
comment
I
think
that
charlie
made
in
the
retro.
Maybe
it
wasn't,
charlie
someone
made
about
having
a
dri
be
in
charge
of
breaking
it
down
earlier
on,
like
while
it's
in
planning
breakdown.
D
Side
there's,
I
don't
know
if
I've
read
the
relevant
comment
in
the
retro
yet,
but
I
I
think
one
concern
we
talked
about
was
like
and
she
doesn't
necessarily
need
to
live
with,
like
the
same
person
who
breaks
it
down,
doesn't
necessarily
need
to
pick
it
up
and
do
the
work.
I
think
you
know
there's
probably
some
benefit
for
that
being
the
case,
but
it's
not
necessarily
always
going
to
be
possible.
D
So
I
think
there
was
some
concern
about
like
kind
of
an
issue
getting
stuck
with
the
person
starting
at
planning
breakdown,
and
then
they
end
up.
You
know,
being
the
person
who
knows
about
it,
so
no
one
else
wants
to
pick
it
up
because
it's
not
you
know,
there's
some
knowledge
lost
there
or
transfer
cost.
But
but
I
think
that's
you
know.
D
Half
of
fixing
half
of
it
or
or
addressing
you
know,
half
of
these
issues
is
going
to
be
done
in
the
planning
breakdown
process
like
going
through
figuring
out
the
scope
of
it
breaking
it
down
into
issues
like
that's.
A
huge
portion
of
the
actual
work
to
be
done,
it
might
only
be,
you
know,
might
be
three
three
weight
of
just
breakdown
and
then
one
weight
of
actually
writing
code.
So
I
don't
know
if
it's
worth
formalizing
that
to
make
it
like.
D
D
B
I
don't
know-
maybe
I
think
ready
for
dev
is
officially
part
of
and
planning
breakdown
or
part
of
the
build
track
and
about
and
like
whatever.
So
I
deleted
the
scheduling
list
from
the
project
management
board
yesterday
and
I
moved
all
the
stuff
that
was
in
scheduling
and
planning
breakdown.
B
So
at
least
we
can
just
move
things
directly
from
there
into
ready
for
development,
but
I
do
think
it
makes
sense
like
if
you
do
more
high-level
release,
planning
and
planning
breakdown
and
then,
like
you,
can
pull
things
like
kind
of
alexander
said
engineers
can
pull
things
into
iterations
from
that
list
of
issues
right,
which
I
think
was
the
whole
idea
behind
having
the
scheduling
list.
But
I
don't
know
if
we
necessarily
need
both.
I
want
to
get
rid
of
as
many
like
lists
as
possible.
So,
however,
we
do
that.
I'm
game.
A
There's
also
the
the
one
kind
of
side
thing
to
this
is
I
have
a
feeling
engineers
or
the
engineers
feel
like
like
the
stuff
they're
working
on
is
product
features
and
building
code,
and
it's
hard
to
reduce
a
little
bit
of
their
capacity
to
dedicate
time
to
the
planning,
so
the
pre
so
planning
breakdown,
as
opposed
to
working
in
devs.
G
Yeah
sorry
zoom
kicked
me
off
for
a
second,
I
just
caught
that
last
statement,
but
so,
if
I
say
something
that
doesn't
track,
it's
because
I
missed
something
important.
So
I
apologize
in
advance
if
that
happens,
but
I
think
like
we
need
to.
We
need
to
like
just
accept
and
appreciate
the
fact
that
the
planning
part
is
important
and
we
can
accept
loss
and
bandwidth
if
it
helps
us
plan
better
right,
because
you
know
with
like
swimming
lanes.
G
We
had
this
nbc
broken
down
into
a
set
of
like
10
issues,
and
it
was
like
hey.
This
is
great.
This
is
a
good
breakdown,
and
now
it's
we've
dug
in
it
we
dug
in,
and
we
found
all
the
intricate
problems
and
the
details
that
are,
you
know:
we've
got
throughout
the
difficulties
that
it's
facing
because
of
xyz,
knowing
that
earlier
probably
could
have
helped
a
lot
of
a
lot
of
the
pressure
and
like
planning
and
setting
expectations
and
so
like
taking
some
time
to
plan
ahead.
G
Even
if
it's
just
at
a
cursory
level,
I
think
ends
up
saving
us
a
lot
of
mental
burnout
in
the
long
run
and
allows
us
to
just
like
understand
the
work
better,
which
I
think
helps
it's
going
to
help
us
all
around.
So
that's
that's
my
take
on
it.
If
somebody
says
hey,
I've
got
to
spend
a
day
digging
into
this.
This
proposed
new
feature
so
that
we
understand
it
and
we
can
properly
scope
the
work
like
I
I'll
take
that
trade
off
every
day.
B
I
would
tend
to
agree
with
that.
I
think
the
basic
idea
is
to
spend
10
or
so
of
your
week
like
refining
issues.
It's
like
a
perpetual
thing
for
product
managers
and
for
the
teams
as
a
whole
and
the
more
the
engineers
are
involved
earlier
on
and
that
the
less
assumptions
product
people
will
make
the
better
solutions
that
will
come
from
things,
because
engineers
understand
how
the
system
works
much
better
than
product
people
and
they
can
make
suggestions
for
accomplishing
the
same
outcomes
with
less
effort.
B
So
like
I've
always
seen
it
super
super
valuable
and
then
the
other
idea
is
like
once
we
do
have
velocity
and
we're
tracking
that
in
the
product
or
as
a
team,
three
iterations,
you
only
schedule
like
eighty
percent
of
of
your
your
capacity
of
your
velocity
and
you
leave
room
slack.
B
So,
like
any
team,
that's
working,
100
capacity
is
incredibly
inefficient,
and
so
you
want
to
build
in
slack
buffers
so
that
you
can
absorb
like
something's,
taking
longer,
there's
others
and
and
doing
you
know,
planning
breakdown
that
sort
of
thing
so
that
people
don't
feel
overwhelmed.
So
I
also
would
take
that
trade
off
gladly.
G
Yeah,
you
know
to
use
a
to
use
a
real
world
example
that
we're
gonna
run
into
here
shortly.
The
idea
of
programming,
epic
boards,
all
right
like
we,
I
would
hope
we
can
avoid
the
same
level
of
I
know
blind
spots.
Aren't
that
isn't
the
right
word
but,
like
I
hope
we
we
can
start
thinking
through
it
and
breaking
it
down
prior
to
the
milestone,
we're
going
to
start
working
on
it
so
that
we
can
have
a
better
indication
of
how
much
work
is
going
to
be
involved.
G
G
If
we
have,
if
alexis
and
I
can
hand
another
epic
nbc
like
feature
broken,
broken
down
into
feature
functions,
what's
the
process
for
the
team
to
be
able
to
look
at
that
and
start
breaking
it
down
in
a
way
that
would
then
make
us
all
comfortable
in
scheduling
the
work.
I
think
if
we
use
a
real
world
example,
maybe
that'll
help
us
with
some
of
those
theoretical
discussions.
H
I
still
feel
like,
including
the
devs
in
that
earlier
discovery
process,
would
be
helpful
in
understanding
the
level
of
effort
that
might
be
involved.
That's
something
that
gabe
and
I
are
looking
into
with
a
checklist
that
will
include
involving
a
developer
or
dev
leader
manager,
of
some
sorts
into
the
brainstorming
and
sort
of
discovery.
Part
of
the
process,
so,
hopefully
that'll
help
we'll
see.
A
Yeah
there's
also,
we
also
need
to
figure
out
how
to
how
to
have
a
buffer
in
some
of
that
stuff,
because,
like
jake
was
saying
earlier
like
if
we're
spending
a
lot
of
our
time
planning
the
majority
of
our
time
planning,
I
mean,
unless
we're
spending,
like
all
of
our
time,
planning,
there's
going
to
be
things
that
we
don't
discover
until
we're
actually
working
on
it
until
we
actually
develop
it.
An
example
of
that
or
with
swim
lanes
is
like
the
sidebar,
no
matter
how
much
thinking
we
did
or
planning
we
did
beforehand.
A
I
don't
know
if
we
would
have
realized
that
the
amount
of
work
that's
involved
in
adding
the
sidebar
to
boards
until
we
actually
got
in
and
started
writing.
G
Code,
oh
yeah,
absolutely
I
I
I
don't
want
it!
I
don't
want
anybody
to
feel
that
there's
this
expectation
that
we're
going
to
have
perfect
planning
and
estimation
like
you,
you
do
this
for
six
months
and
you
realize
that's
never
going
to
happen
right,
but
I
think
there's
a
gap
between
where
we're
at
now
and
that
you
know
theoretical
never
exists,
perfect,
that
we
can.
G
We
can
get
more
efficient
in
just
to
help
us
all
through
it,
and
so
it's
more
just
like
okay,
even
if
the
estimation's
like
20
percent,
more
accurate
than
what
we
have
now.
That's
a
major
huge
improvement
right.
B
Yeah,
I
I
don't
think
you
ever
ever-
want
to
invest
that
much
in
planning,
because
we're
taking
away
investment
and
building
so
the
whole.
The
whole
reason
why
I
use
like
story
points
or
weight
and
iterations,
and
these
like
they're
supposed
to
be
super
lightweight,
and
so
you,
if
you
don't
know
how
to
weight
something
you
do
like
a
20
or
30
minute
research
spike
to
get
just
enough
information
in
order
to
estimate
it.
B
But
the
estimates
are
never
going
to
be
accurate,
but
the
thing
about
it
is
that
they're
always
going
to
be
consistently
inaccurate.
As
long
as
the
same
team
is
together,
so
you
still
get
the
benefit
of
a
velocity,
and
that's
where,
like
I
like,
the
idea
of
of
like
as
things
like,
maybe
looking
at
a
big
issue
like
swim
lanes
and
or
epic
boards
and
breaking
it
down
into,
like
you
know,
logical
chunks
of
saying
hey
when
we
build
this.
B
Here
are
the
high
level
things
you
know
so
to
speak,
and
then
that
kind
of
like
informs
what
issues
we
create
and
then,
as
those
issues
get
pulled
into
iterations,
they
get
estimated
like
the
only
thing
that
matters
is
that
we
have
a
weight
on
an
issue
before
it
gets
assigned
to
an
iteration
right,
because
that's
how
like,
eventually,
you
establish
velocity.
B
A
Cool
we
want
to
continue
the
conversation
in
the
dog
fooding
issue.
B
Yeah
I
wanted
to
kind
of
cover
this
one
thing,
because
I
dropped
a
it's
under
anything
else.
I
dropped
a
note
about
about
this
in
our
13.2
retro,
but
I
also
just
want
to
kind
of
like
talk
about
it
and
explain
so
that
there's
a
kind
of
at
least
basic
understanding,
and
so
one
of
the
things
that
scott
williamson
and
I
think
worked
with
the
noop
that
they
did.
B
Is
they
looked
at
preparing
this
rationalization
for
investment
in
r
d
by
stage
based
on
a
couple
different
factors,
so
they
kind
of
classified
like
each
of
these
based
on.
If
it's
a
usage
driver,
I
meaning
like
how
many
people
are
using
it
right
now
and
you
can
kind
of
see
right
there
that
there's
about
five
different
categories.
I
think
right
now
we
fall
into
this
range
right
here,
which
is
a
four
our
revenue
driver
score,
which
means
like,
I
think
it's
basically
do.
B
You
have
a
key
feature
or
features
in
ultimate,
and
how
much
is
that
driving
revenue?
I
think
we
got
putting
it
at
three
right
now.
I
don't
necessarily
agree
with
that,
but
it
is
what
it
is
and
then
our
there's
a
proposal
in
to
update
that
to
a.
B
Okay,
cool
the
sam
driver
score
is
our
serviceable
addressable
market,
which
means
how
many,
how
many
people
can
we
potentially
serve
with
the
plan
product
itself
and
all
the
sub
categories
and
features
and
like
how
many
people?
How
big
is
it?
And
then
you
get
this
like
combined
score
and
so
all
the
different
stages
get
a
combined
score.
B
So
we
get
a
percentage
of
all
like
the
points
and
basically
we
have
14.6
percent
of
all
the
points
across
all
the
stages,
but
our
our
stage
level
development
spin
is
at
seven
and
a
half
percent,
and
so
we're
basically
underfunded
by
100
at
this
point
right
now,
so,
like
there's
been
a
lot
of
like
feedback
from
engineers,
and
I
and
I
feel
too,
like
we
have
all
the
stuff
we're
trying
to
do,
and
these
big
things
I
feel
overwhelmed.
B
I
feel
like
we
don't
have
enough
support,
and
I
I
this
this
is
just
like
quantitative
data
suggesting
why
that
that
feeling
is
there,
and
we
talked
to
scott
a
little
bit
about
this
and
asked
him
how
we're
gonna
fix
it.
And
I
don't
know
if
there's
anything,
we
can
necessarily
do
for
this
fiscal
year.
But
I
know
it's
one
of
his
goals
and
eric's
goals
to
get
this
variance
down
to
zero
percent,
which
means
like
when
we
do
fiscal
22
planning.
B
Hopefully
this
helps
make
the
case
of
why
we
need
more
more
team
members,
but
I
think
in
the
interim
I
would
just
suggest
us
to
continue
to
think
about
how
we
can
support
one
another
and
like
do
things
that
help
us
not
feel
pressured
and
stressed,
while
realizing
that
we
have
a
lot
on
our
plate
and
we're
juggling
a
lot.
And
if
that
means
cutting
a
few
things
or
limiting
the
work
in
progress
or
whatever.
B
That
is,
I
don't
know
the
solution,
but
just
saying
like
you
think
we
need
to
almost
like
band
together
and
figure
out
how
to
help
ourselves
stay
present
and
not
overwhelmed
and
not
burn
out
over
the
next
six
months
and
then
hopefully
after
that,
we'll
get
some
more
support.
But
I
just
wanted
to
share
that
with
everyone.
So
they
had
context.
D
What
is
the
group
of
people
who
assembled
that
like
like
at
what
at
what
level
is
that
argument
made?
I
guess
currently
which
argument
well
so
like
this
is
a
very
clear,
like
example
of
like
out
of
all
the
you
know,
all
the
lines
on
this
this
table.
We
are
like
easily
the
furthest
away
from
where
we
should
be
with
like
the
next.
You
know
the
next
one
is
negative,
four
and
we're
at
negative
seven.
D
D
G
G
And
there
is
a
level
of,
I
think
advocacy
that
needs
to
happen
from
everyone
in
this
call
up
to
continue
this
conversation
and
continue
to
point
at
it
and
then
the
level
of
decision.
I
I
mean,
I
think
it
starts
at,
like
the
group
managers
all
the
way
up
to
the
directors
and
then
to
the
vps
of
when
there
is
resource
allocation
discussions
that
all
of
this
data
is
up
on
the
table
at
the
same
time,
so
that
they
can
make
the
best
choices.
B
Also
things
worth
saying
part
of
what
led
to
this
is:
there
was
there's
like
five
main
themes
that
we,
as
a
company,
wanted
to
focus
on
for
fiscal
year.
21
plan
was
the
fourth
out
of
the
five
and
then
when
the
covet
thing
happened
and
we
basically
slashed
our
slashed,
our
spending
and
we
cut
the
bottom.
The
last
two
themes
is
things
that
we
could
reasonably
like,
deliver
and
set
expectations
that
we
could
deliver
this
year
because
of
basically
the
safety
net
of
we
don't
want
to
over
commit
ourselves.
B
We
want
to
make
sure
that
we
have
enough
room
when
we're
in
the
bank.
We
don't
want
to
grow
faster
than
we
think
we
reasonably
can
and
so
that
that's
naturally,
just
like
what
happened
is
is
that
the
plan
was
the
fourth
one
it
got
cut,
but
it's
not
like.
We
don't
have
support.
It
was
like
a
very
rational
business
decision
of
why
that
why
it
happened
this
year,
but
that's
also
why
scott
and
eric
have
said
like
it's
our
goal,
to
get
that
back
to
zero
for
the
next
year.