►
From YouTube: Plan 12.4 initial planning meeting
Description
A
C
Wonderful
all
right
here
we
are
okay,
so
kind
of
a
high
level.
This
is
canyons
first
second
week.
I
guess
here
that
help
you
taking
over
all
the
portfolio
management,
stuff,
I've
kind
of
left
that
there
and
I
want
to
work
together
as
a
team
to
figure
that
out
and
kind
of
discuss
the
best
way
to
like
split
and
where
things
are
gonna
be
split
like
technically.
At
this
point,
in
my
mind,
it's
you
know
the
portfolio
management
pieces,
epics
and
roadmaps,
and
that's
the
bulk
of
it
right
now,
but
it
can
probably
evolve.
C
I
think
the
scope
for
everything
else
that
was
in
team
planning
that
project
management
is
the
same.
So
like
there's,
no
real
changes
other
than
changing
the
name
and
getting
rid
of
a
category.
So
now
the
categories
it's
more
or
less
like
the
the
encompassing
focus
and
then
there's
going
to
be
some
I
mean
the
group
is
there's
gonna,
be
some
categories
that
will
fall
out
of
that
at
some
point
in
the
future,
but
the
biggest
thing
that
I
see
us
needing
to
do
based
on
feedback
from
customers
and
I.
C
C
C
All
right,
so
it's
this
one.
This
has
a
couple
I
guess
customer
stories
in
it,
and
it's
where
it's
like,
looking
at
its
epic
1/7
1715
and
the
gitlab
or
group
and
I
think
this
kind
of
like
lays
out
a
high
level,
is
vision
of
what
we
want
to
work
for
solving
over
the
next
several
months
and
it
kind
of
encapsulates
a
lot
of
good
feedback
on
what
or
what
we're
missing.
C
C
I
think
that's
the
other
thing,
let's
see
here
from
your
tree
child
the
we're
addressing
this
largely
with
the
epic
tree,
which
kind
of
is
a
little
bit
in
limbo.
I
guess!
The
path
forward
right
now
is
to
make
it
so
that
you
can't
move
issues
within
from
epidemic.
But
that's
like
a
temporary
thing,
we'll
need
to
work
towards,
but
I
think
the
relationship
of
the
roadmap
is
like
an
important
thing.
The
other
one
is
like
there's:
no
visibility
from
a
high
level
of
organizational
dates.
Deliverables
like
there's
a
screenshot
from
rally
here.
C
If
you
want
to
look
at
it,
but
it's
more
or
less
having
like
a
real
road
map
view
that
has
the
relationships
built
in
as
well
as
like
completion
criteria
when
things
are
and
how
things
are
cracking
and
progressing
so
that,
like
you,
have
your
kind
of
two
sets
of
user
groups,
you
have
your
executives
and
director
levels
that
are
going
to
want
to
use
the
road
map
view
to
get
a
sense
of
like.
Are
we
as
an
organization
tracking
along
where
you
need
to
be?
And
then
you
have.
C
C
I
think
this
is
also
just
like
a
terminology
thing
where
a
lot
of
agile
methodologies
don't
use
the
concept
of
milestones
or
issues
they
use
stories
and
story
points,
not
weights
so
like
this
is
a
I'm
not
as
worried
about
this
because
we
can
solve
for
it
later
with
you
know,
other
things
and
I
think
this.
This
particular
user
was
like
it's
fine
like
we
can
get
used
to
it.
If
that's
what
it's
going
to
be,
but
it's
just
really
weird.
So
that's
a
lower
priority
in
my
standpoint
and
then
kind
of
going
through
here.
C
This
talks
about
like
an
actual
use
case
where
there's
like
a
large
project,
requires
collaboration
between
four
different
teams.
You
know,
let's
say:
there's
ten
features.
Three
milestones
the
overall
product
manager
works
with
other
stakeholders.
Then
there
needs
to
be
a
way
to
lay
up
a
high-level
view
and
plan
and
then
like
indicate
the
parent-child
relationship
which
I
think
we're
not
that
far
off
from
that,
then
the
plan
needs
to
be
able
to
refined,
ideally
without
screen,
switching
tab
breakdowns
and
so
the
leaf
items
are
story,
small
enough
to
be
done
in
the
sprint.
C
So
that's
kind
of
one
of
the
issues
that
we've
been
talking
about
is
like
if
I
want
to
work
within
the
epic
view
right
now
and
I
want
to
work
on
issues,
I
have
to
either
go
open,
a
new
tab
or
use
like
open
and
then
go
back
or
just
like
do
a
lot
of
context.
Switching
that
kind
of
breaks,
the
flow
of
like
I,
want
to
work
to
break
these
things
down,
and
then
the
other
one
is
in
terms
of
like
executing.
Oh,
this
is
another
import.
One
is
the
idea
of
user
story.
C
Size
needs
to
be
a
first
class
concept.
We
have
like
a
wait,
but
I
think
this
particular
use
case
was
saying
like
when
I
were
looking
at,
let's
say
an
issue
board
and
we
have
a
list.
It's
our
backlog
and
we're.
You
know
together
as
a
team
in
a
room
sitting
like
we
need
a
way
to
easily
go
through
and
have
like
kind
of
just
like
a
quick
way
to
do,
burn,
downs
and
estimate
those
things
and
to
talk
about
them.
C
C
And
I
guess:
I
changed
it,
but
the
whole
gist
is.
This
is
a
I
guess:
I
moved
to
different
site?
It's
like
it's,
it
kind
of
turns
it
all
into
like
game
where
you
can
go
through
and
you
can
easily
like,
as
a
team
:
your
list
see
from
your
backlog
and
you
kind
of
like
each
score
your
things.
Then
it
will
pull
together.
A
aggregate
score
median
score
then
associates
that
story
which
syncs
back
to
like
the
third
party
or
external
issue
tracker
that
you're
using.
C
C
That's
there,
and
this
is
more
around
like
looking
at
your
estimates
versus
actuals,
and
so
the
basic
idea
is
like.
If
we
have
100
points
or
100
wait
in
the
backlog
and
we're
doing
X
amount
of
weight
per
Sprint
or
prochaine
per
iteration,
then
the
amount
of
work
that
has
been
scooped-
that's
ready.
For
you
know,
the
development
is
gonna,
take
about
four
weeks
and
I
think
this
kind
of
gets
into
some
stuff
that
we've
had
internally,
where
Sean
you're,
like
I
kind
of
just,
do
it
by
my
gut.
C
But
it's
not
always
right,
but
I've
been
here
long
enough,
so
I
have
a
pretty
good
sense
of
it
and
I
think
it's
taking
that
kind
of
sense
that
you
have
of
like
what
the
team
can
relatively
do
and
Miki
into
more
of
a
quantitative
number
that
can
be
sure
externally
and
rely
upon
and
then
along
with
that,
like
having
burndown
charts
that
kind
of
track
along
those
different
things.
Looking
at
a
velocity
of
a
team
over
like
certain
period
of
time,
we've
also
served
surface.
C
This
tube,
like
the
engineering
manager,
I,
think
I,
talked
to
one
and
secured,
and
he
maintains
a
separate
issue
board
that
has
all
the
engineers
on
it
and
then
that
way
he
he
wants
to
have
sub
issues.
So
each
engineer
has
a
single
issue
that
they're
assigned
to
with
nobody
else
that
has
no
other
weights
and
other
than
that
engineer,
so
that
you
can
do
effective
like
capacity
planning
and
then
there's
a
lot
of
other
things
just
like
around
daily
stand-ups
and
wishing
that
was
integrated
and
I.
C
Think
that's
going
to
be
something
that
happens
later,
but
all
that
kind
of
feedback-
and
you
can
read
this
work
kind
of
comes
into
wanting
to
put
together
a
plan
of
like
how
do
we
get
from
where
we
are
today,
something
that
better
addresses.
What
is
a
traditional,
agile
project
management
methodology
methodology
that
a
lot
of
these
companies
use
does
that
make
sense,
Phoebe
questions,
pushback.
E
The
last
two
releases
so
I
know
there's
some
kind
of
thing
there.
Where
we
like
double
the
number
of
points
we
do
and
we
take
stuff
right
through
the
D
scope
stuff
through
them
throughout
the
milestone,
but
like
an
in
the
past,
I've
actually
used
those
exact
and
was
it
Mountain
Goats
or
whatever
planning
poker
cards
and.
A
B
For
a
while,
we
tried
a
thing
where
we
said
that
we
were
aiming
to
ship
roughly
seventy
percent
of
what
we
put
in
a
milestone
and
I.
Think
there
you
have
a
problem.
You
can
also
replace
the
okay
house,
but
I
think
it's
word
is
slightly
different
there,
which
is
just
that
it
encourages
you
to
pad
it
by
like
50
percent,
rather
than
actually
taste
change.
C
Yeah
I
think
that's
well
good.
It's
confusing
for
me
too,
just
because
I
like
I,
don't
look
at
the
the
burndown
is
like
a
reflection
of
the
team's
capabilities,
I
look
at
as
a
reflection
of
a
bigger
system
or
like
there's
any
given
different
variable,
that's
influencing
of
whether
something
gets
done
or
not.
Right
and
I
know.
There's
there
are
the
tendencies
for
some
organizations
to
hyper
focus
on
like
a
velocity
number
and
like
judge
a
team's
performance
based
on
that
velocity,
without
taking
account
like.
Are
they
blocked
by
things?
C
Is
there
a
lot
of
talent
with
that
like?
What's
the
underlying
root
cause
of
why
things
are
going
slow
like?
Is
there
a
product
manager,
who's
not
reviewing
things,
but
all
that
to
say
is
like
I
would
like
us
to
see
getting
the
point
where,
when
we
put
something
in
a
release
where
we
have
a
high
confidence
level
that
it
can
be
done
and
that's
where
it's
not
just
velocity.
C
They
want
both
but
I
will
say
like
overall
in
the
broader
market,
there's
a
higher
percentage
of
companies
that
are
practicing
scrum
and
but
much
smaller
percentage
of
companies.
They're
practicing
Kanban
I.
Think
it's
something
like
54%
to
80%,
but
I
think
we
kind
of
need
to
work
toward
supporting
both,
so
that
was
kind
of
just
of
this,
and
instead
of
like
hyper,
focusing
on
a
given
methodology,
I
kind
of
think
about
it
as
two
forms
of
planning
one
is
continuous
and
one
is
time
boxed
right.
C
C
And
so
then
you
can
either
adjust
scope
or
you
can
adjust
time,
but
you
can't
like
do
both
so
there's
like
kind
of
different
nuances
to
each,
but
I
would
I
think
with
our
kind
of
core
construct
of
the
issue
boards
right
now
we
can
get
to
to
supporting
both
fairly
straightforward
way
underpinning
all
that
is
like
the
desire
to
want
to
build
a
more
modern
and
collaborative
experience.
It
means
the
work
on
I.
C
B
B
C
C
Cool,
so
real-time
board
lists
back
in
I.
Think
like
this
kind
of
brings
us
to
like
a
strategy
of
this
is
like
an
angle,
but
there
are
probably
like
little
little
things
that
we
can
do
to
get
there
along
the
way
to
test
things
like
you
know,
to
build
more,
remember,
bike
kind
of
viable
changes
that
make
sense
and
I
haven't
updated
this
card
yet,
but
I
wanted
to
talk
through
some
of
these
things
like
the
basic
idea
for
config
changes.
This
is
not
in
scope.
C
B
Because
of
the
efficient,
because
that's
already
like
portable,
that's
actually
not
too
hard
to
do.
Necessarily
we
just
went
the
caching
we
have.
It
wouldn't
be
very
useful
to
just
update
the
titles
and
descriptions.
Well,
you
can't
see
a
description
on
the
board
anyway.
At
the
moment,
it
wouldn't
be
too
useful
to
just
update
the
titles
in
real
time
on
the
board.
I,
don't
think
that's
what
anybody
sees
is
a
viable
MVC
for
that,
like
so
yeah
I
think
the
last.
C
Two,
okay,
and
so
this
is
more
or
less
a
changes,
labels
Sinese
milestones
and
they
appear
on
different
lists
of
the
board
or
somebody
just
like
I
guess:
I
guess
this
is
not
here.
Oh
I
guess
changing
labels,
but
in
the
specific
use
case
of
like
I,
drag
an
issue
from
one
lane
to
another.
You
know
depending
on
like
sometimes
that's
not
if
it's
not
scope
label.
It's
not
gonna
update
the
labels,
it
might
not
update
the
milestones,
but
that
gets
the
basic
gist
of
like
if
a
label.
B
B
But
you
can
also
move
an
issue
between
lists
by
just
updating
the
labels
on
the
issue
or
by
updating
the
assignees
on
the
issue
or
by
updating
the
milestones
on
the
issue.
So
I
think
the
way
it's
written
that
way
to
say
that
it
doesn't
matter
where
the
change
comes
from.
The
board
should
reflect
that
yeah.
Actually,
it
would
be
a
lot
easier
to
do
it
if
the
change
could
only
come
from
the
same
board
but
I,
don't
think
that
would
be
very
intuitive
and
we,
the
other
problem,
is
like
you
know.
C
B
C
C
Question
right,
quick,
just
to
make
sure
we're
like
going
down
the
best
best
path
and
I
totally
defer
to
you
guys
for
the
technical
decisions,
but
I
do
have
a
decent
amount
of
experience
with
graph,
QL
and
and
just
like,
with
Apollo
and
I.
Think
we're
using
Apollo
on
the
front
end
right
and
if
we
are
then
all
uses
some
I'm,
not
sure
what
you
of
the
Apollo
integration
looks
like,
but
it's
probably
using
view
X
under
the
hood
already.
C
So
when
I
was
using
like
graph
QL
Apollo
with
react
and
redux,
it
got
to
the
point
where
Redux
was
kind
of
like
a
little
bit
like
unnecessary,
especially
after
Apollo
added
the
support
for
local
storage
or
local
state.
So
that
way
like
it
would,
you
could
define
things
that
were
outside
of
your
queries
and
mutations
and
store
that
in
the
same
store
and
so
like.
It's
almost
like,
there's
a
duplicated
like
effort
and
I.
Guess
that's
just
where
from
like
a
technical
standpoint.
A
I'll
share
the
main
kind
of
architecture
issue
around
eventually
getting
over
everything
over
to
Apollo,
but
I
do
think
that
is
the
ideal
and
result
is
the
not
used
view
X
and
to
move
everything
over
to
a
polygraph
QL
as
far
as
this
one,
so
we're
we're
using
graph
QL
has
primarily,
at
least
on
our
team
on
the
front.
End
has
been
around
epics
and
the
epic
tree
we
haven't
done
much
as
far
as
the
the
AP
is
that
the
board's
uses
to
get
that
in
the
graph
you,
oh
yeah.
A
B
I
think
from
the
back
in
perspective,
like
the
current
code,
is
not
really
a
concern,
but
it
you
know
we
don't
provide
this
information
through
graph
QL.
So
then
the
question
is
like:
do
we
want
to
add
to
the
scope
of
the
refactor
by
getting
to
the
desired
end
state
sooner
by
sort
of
going
rewriting
the
store
and
also
using
graphic
UL,
or
do
we
want
to
split
them
up
and
take
more
time
overall
I
know
I,
don't
know
the
answer
to
that
like,
but
that's
the
trade-off
as
I
see
it
well.
C
B
So
there
are
two
future
states
here
that
we're
talking
about
I
just
want
to
make
sure
I'm
understanding
so
like
one
future
state
is
from
like
a
technical
perspective.
We
want
to
use
graphic
UL,
but
for
users
that's
not
super
interesting.
It
is
useful
to
people
who
are
using
the
graphical
API
themselves,
but
for
most
people
it's
not
that
interesting
that
the
end
state,
that's
most
user
impactful.
Is
this
one?
The
real-time
boards
right?
That's
the
they
go.
C
Yes
is,
but
we
also
like
in
have
it
on
a
roadmap
to
do
all
that
other
stuff,
so
does
I,
guess
I'm,
just
saying
like
which
one
is
gonna,
make
the
most
logical
sense
and
prevent
or
produce
the
least
amount
of
duplicated
effort.
In
the
long
run
like
let's
say
we
have
everything
working
yeah,
that's
where
it's
like
yeah.
B
C
I'm
open
to
either,
like
I,
think
you
know,
I
want
to
get
value
to
the
customers
as
quickly
as
possible,
but
I
also
want
to
build
things
in
a
way
that
enables
us
to
move
faster
down.
The
road
and
like
I,
know
how
for
me
personally
as
a
front-end
engineer,
I
prefer
working
with
graph
QL
over
rest
api's
and
how
much
faster
and
easier
yes,
but
that's
just
my
experience.
I'll
leave
it
up
to
you
guys.
C
Should
it
get
scoped
to
that
board
and
I
think
this
is
like
the
biggest
thing
that
I
would
like
to
see
because,
like
right
now,
looking
at
the
burndown
for
a
given
milestone,
it's
hard
to
see
like
what?
What
is
the
dev
ops
plan
role
in
this
and
where
are
we
at
so
I?
Think
there's
like
a
lot
of
proposals
here,
one
FERS
making
this
like
I
guess
having
a
where
is
it
on
this
view?
C
B
I
did
have
one
question
which
was
sort
of
a
general
question
just
because
that
I,
why
didn't
occur
to
me
before,
but
like
there's
ant,
there's
a
analytics
group
that
burned
down
shouts,
don't
belong
in
the
unless
use
group.
They
belong
in
the
planned
stage,
but
I'm
not
sure
that
I
mean
you
could
make
a
case
for
it,
I'm
just
not
sure
which,
which
way
we
want
to
end
up.
B
Second
thing
is
just
to
check
that
we
want
the
burndown
chart
to
work
with
the
current
state
of
things,
so
we
don't
want
to
say
there
were
20
issues
in
devops
plan
yesterday,
but
then
we
relabeled
ten
of
them
to
like
not
be
DevOps
plan.
So
today
there
are
10,
but
we
didn't
close
any
either.
There
are
just
ten
like
do
we
want
to
track
that?
Or
do
we
just
want
to
say
the
issues
that
are
in
DevOps
plan
now
have
followed
this
course
throughout
the
month.
I
think.
C
It
followed
this
course
throughout
the
month.
If
the
issues
get
moved
elsewhere,
then
that's
the
same
thing
as
adding
a
reducing
scope
to
any
given
like
thing
right
so
like
I,
don't
see
that
as
an
issue,
the
thing
that
is
weird
to
me
in
this
case
like
for
our
use
case,
we
use
a
board,
but
it's
not
scoped
to
a
specific
milestone.
It's
cooked
to
like
a
label,
and
then
we
have
sub
scopes
for
groups
and
I.
C
Think
this
kind
of
gets
into
the
mechanisms
of
like
one
of
the
other
issues
we'll
talk
about
is
multiple
milestones
per
issue
and
it.
How
do
we
want
to
reconcile
like
we're
working
on
a
current
release,
but
our
board
isn't
scoped
to
that
specific
release
a
should
it
be
or
be
like?
Do
you
allow
people
to
select
different
milestones
in
this
view?
To
like
view
them,
you
know,
I,
guess
that's
the
thing.
Yeah.
C
What's
the
cycle
Analytics
report,
where
the
different
stages
can
be
configured,
so
you
can
say
you
know
like
the
back
the
backlog
stage,
the
planning
stage,
the
in
development
stage
and
their
mapping
that
to
the
actual
events,
if
I
think
from
the
events
API
and
then
based
on
that
they're
gonna
run
analytics
against
merge
request,
but
they
haven't
quite
figured
out
how
to
incorporate
issues
into
that
and
so
I'm
trying
to
do
partner
with
them.
But
the
way
that
I
kind
of
like
see
this
in
a
perfect
world
is
like.
C
Ideally,
we
give
teams
the
option
or
like
on
a
board
the
option
to
set
like
some
sort
of
recurring.
You
know
really
schedule
or
sprint
schedule,
and
then
we
ought
to
generate
milestones
for
them
and
let
those
milestones
get
associated
to
an
issue
and
then,
like
that's,
comes
after
you
can
have
two
milestones
for
issue.
So
do
we
want
to
like
table
this
and
focus
on
the
other
things
that
would
make
this
more
meaningful
for
a
poor
or
like?
What's
I
guess
that's
where
it's
hard
to
understand
what
the
relative
complexity
is
of
just
like.
C
B
D
F
F
B
B
Sorry
yeah
back
to
the
main
point.
So
there
are
a
couple
of
things
here
like
I,
don't
think
scoping
the
data
for
a
burn
down
charts
to
match
a
broad
scope,
assuming
that
also
includes
a
milestone.
Somehow
is
particularly
hard
from
the
backend
perspective,
but
we
were
just
talking
about
like
if
we're
putting
up
on
a
board
itself.
We
were
just
talking
about
sort
of
technical
there
in
boards,
so
I
don't
know
Donald
how
much
impact
that
would
have
there.
A
Yeah
we'd
probably
still
want
to
do
to
refactor
the
boards
first,
but
I
think
even
I
was
just
looking
through
kind
of
the
the
mocks
that
we
have
for
this,
and
we
can
kind
of
we
might
be
able
to
treat
it
somewhat
separately
from
the
actual
kind
of
like
its
own
own
page.
So
it
might
not
be.
We
might
be
able
to
work
on
this
in
parallel
to
the
refactor
of
boards.
A
C
I
think
that's
the
thing
just
like
I
we're
gonna
issue
boards
are
going
to
become
an
increasingly
fickle
part
of
like
the
project
management
group
and
facilitating
workflows
and
I
want
them
to
be,
and
they
should
be
so
things
like
I
would
say
from
every
release,
we're
gonna
be
doing
stuff.
That's
either
adding
functionality
or
refactoring
or
improving
air
or
making
things
do
differently
from
like
what
the
card
faces.
C
Look
like
on
the
issue
board
so
like
what
stuff
is
real-time
to
what
other
things
we
add
like
and
how
we
can
scope
it
and
like
there,
it's
gonna,
you
know
even
getting
the
point
where
we
have
swim
lanes
like
horizontal
or
vertical
swim
lanes.
You
know
within
each
list
you
can
break
the
list
at
a
different
swim
lanes.
C
There's
a
lot
of
things
that
I
think
we're
gonna
want
to
do
in
the
next
year,
and
so,
if
we
need
to
just
like
slow
down
and
refactor
the
boards
to
get
them
correct
and
maybe
use
something
like
the
real
time
piece
to
make
that
like
to
support
the
memory
group
as
they
do
that
as
an
actual
feature
in
these
case.
That
makes
the
most
sense
to
me.
C
Instead
of
stuffing
these
things
and
then
that
would
give
us
a
little
bit
more
time
to
like
do
some
customer
discovery
and
validation
to
say
like
exactly
how
should
this
work
and
how
should
the
Scopes
work
and
should
we
have?
The
idea
of
you
know
sprints
and
iterations
of
some
form
or
auto-generating
milestones?
Does
that
make
sense.
C
G
Yes,
cool
yeah,
I
agree
with
you,
I
think
you
know
there
is
only
that
trade-off
of
delivering
something
quickly,
but
the
idea
that
we
can
lay
stronger
or
better
foundation,
so
we
can
iterate
quicker
in
the
future.
I
don't
know,
that's
it
for
me,
that's
often
an
easy
trade-off,
but
I
think
I
think
we
want
to
also
get
to
the
point
where
we
can
make
faster
changes
as
we
discover
more
stuff.
C
Quick
I'm
gonna
skip
over
the
cumulus
cloud
stuff
because
I
think
that
should
live
in
analytics,
but
the
basic
idea
is
it's
sort
of
close
to
a
the
cycle
analytics.
It's
just
a
different
presentation
of
the
data
and,
like
I,
think
it's
an
important
thing
that
we
need
to
add
very
quickly,
but
it
makes
sense
to
me
to
figure
out
how
to
bring
in
the
idea
of
like
a
workflow
first,
you
can
have
it
based
on
labels.
C
C
See
here
this
is
also
along
the
similar
type
line
of
a
small
thing.
We
maybe
could
work
towards
doing
but
like
right
now,
I
think
the
the
burnout
charts,
they're,
stateless
I,
guess
the
question
number
one
is:
do
we
want
to
formally
ask
this
move
into
the
analytics
group
if
we
maybe
so,
will
contribute
to
it?
If
we
don't
get
support
to
move
it
along
in
time,
but
as
a
baseline
thing
should
burn
downs
live
in
analytics.
B
Like
you
know,
when
we
did
the
headcount
planning
for
FY
20,
so
fi
20
starts
in
February
2019
and
ends
in
the
end
of
January,
2020
I
think
we
use
the
categories
that
were
on
the
the
pager
on
at
the
time
and
those
have
changed
slightly
since,
but
it
wasn't
a
burn
down
category
then,
and
there
isn't
a
burn
down
category
now,
I'm
guessing
it
fit
into
project
management
before.
But
we
didn't
have
an
explicit
like
this
is
how
much
capacity
we
expect
to
be
spending
on
burn
down
chart
specifically
then
and
I.
B
B
If
we
don't
have
a
category-
and
we
haven't
thought
before
about
like
how
much
time
we're
specifically
sent
spending
and
burn
down
charts
I
think
both
sound
reasonable
to
me,
like
I,
don't
think
either
is
a
terrible
decision,
so
yeah,
maybe
maybe
making
a
category,
would
be
the
first
step
and
just
sort
of
trying
to
track
how
much,
how
much
effort
we
do
put
into
it
now
and
how
much
effort
we
want
to
put
into
it
would
be
a
good
stir.
Okay,
yeah.
A
B
Believe
yeah,
it's
the
analytics
group
inside
the
EM
manage
stage,
so
the
analytics
group
currently
is
responsible
for
develops
core
code
analytics
and
value
stream
management,
and
then
burndown
is
slightly
different
because
it
of
those
analytics
items
it's
the
only
one.
That
only
applies
to
issue
tracking,
which
is
I,
guess
where
you
could
say
that
it
belongs
in
the
project
management
side.
But
we
haven't
explicitly
called
that
out
at
any
point.
So
I
think
it
might
be
useful.
Maybe
it's
I
don't
know
if
it
like
qualifies
as
a
product
categories.
C
I,
don't
think
it
I
wouldn't
put
burn
on
its
own
category,
but
what
it
does
belong
in
is
a
category
around
like
I,
don't
know
what
the
name
is,
but
cumulus
low,
like
you're
burned
down.
All
that
stuff
is
really
just
giving
you
insight
is
whether
you
have
the
right
capacity
resources
allocated
to
completely
given
scope.
C
So,
like
in
your
triangle,
you
have
scope
time,
resources
or
costs
one
anyway
and
like
it's,
making
decisions
around
and
trade-offs
for
those
things,
and
so
I
think
there
is
a
lot
of
good
there's
some
overlap
with
value
stream
management,
but
not
really
because
it's
not
they
value-free
management.
It's
like
a
higher-level
look
at
like
lots
of
things,
and
this
is
applicable
to
like
a
team,
so
I
will
work
to
bring
some
more
clarity
around.
C
That
and
I
also
think
we
should
connect
with
Virginia
and
talk
about
how
we
want
to
overlap,
and
now
that
we
have
like
a
set
of
things
that
we
need
to
do,
because
this
is
what
customers
want.
This
is
not
like
you
know,
this
has
to
happen
for
them
and
for
them
to
use
the
the
project
management
tools
effectively,
how
to
like
a
tangible
roadmap.
I
guess
lead
to
work
together
with
them
or
to
take
this
stuff
on
so
we
can
set.
F
C
B
A
bunch
there's
a
related
issue
that
I
added
there
I
recited
in
the
description.
It's
called
instance
level
ethics.
So
the
concern
with
having
so
the
moment
boards
can
only
sort
of
flow
downwards.
If
that
makes
sense,
you
can
have
a
board
on
a
parent
group
and
it
can
see
everything
in
its
children
groups.
You
can
have
a
board
on
one
of
those
child
groups
and
you
can
see
everything
below
it,
but
it
can't
see
anything
adjacent
to
it
and
he
siblings,
and
it
can't
see
anything
above
it
and
what
that
means
is
for
assignees.
B
This
doesn't
really
matter
too
much,
but
in
terms
of
like
permissions
for
viewing
the
board,
it
can
be
very
straightforward
permissions
for
can
you
move
a
thing
can
be
really
straightforward
and
also
what
objects
you
use.
So,
for
instance,
you
have
a
label
list
on
a
board.
If
you
have
I,
don't
know
the
DevOps
double
colon
plan
label
on
a
board,
and
you
have
two
different
groups
that
both
have
the
DevOps
double
colon
plan
label.
Do
you
need
to
add
two
lists?
B
You
need
to
add
one
list,
but
when
I
say
they
have
a
label,
I
mean
they
have
a
label
with
that
name.
That's
the
tricky
part
there
I
did
suggest
in
the
instance
level
Epic's
thing,
because
epochs
behaving
the
same
way
right
that
you
can
only
add
a
thing
to
an
epic
if
it's
below
in
the
hierarchy-
and
we
have
this
problem
where
we
have
at
least
two
top
level
groups.
B
So
it
works
for
like
labels
milestones
boards
epics
stuff
like
that,
but
it
doesn't
work
for
membership
and
that
might
be
related
to
teams
too,
because
at
the
moment
you
have
to
use
groups
for
everything
related
to
organizing
things.
So
a
portfolio
might
be
a
way
of
organizing
like
your
project
management,
stuff
and
across
multiple
projects
or
portfolio,
I,
guess
and
then
a
team
might
be
a
way
of
managing
organizing
people
that
isn't
a
group
necessarily
and
those
two
things
seem
kind
of
related
to
me.
But
yeah.
Thank
you
for
coming
to
my
TED
talk.
B
F
B
So
yeah
there's
a
specific
issue,
about
instance,
level,
epics
I
think
anything
instance.
Level,
obviously,
is
a
challenging
idea
on
a
multi-tenant
instance
like
it
lab
calm,
because
you
know
they.
If
you
could
only
manage
that,
if
you're
an
administrator
it
works
for
us,
but
it
doesn't
work
for
everybody
else.
Using
git
lab
calm,
but
having
an
arbitrary
collection
of
groups,
in
particular
I
think,
is
valuable,
I'm,
less
convinced
about
the
value
of
an
arbitrary
collection
of
projects
for
stuff
like
this.
This
is
how
I
would
look
at
look
at
it.
B
C
Yeah,
okay
I
will
spend
some
time
in
digesting
all
this
I
don't
want
to
take
time
to
do
it
here,
but
this
also
kind
of
relates
to
another
I.
Don't
have
the
issue
in
front
of
you,
but
more
or
less
people.
You
know.
Internal
customers
have
expressed
the
most
pain
point
that
I've
seen
just
but
being
able
to
work
across
these
two
groups,
which
they
can't
do
right
now
in
any
sort
of
way.
C
B
C
B
Just
just
just
to
be
clear
there
as
well
like,
like
I,
don't
think
my
proposals.
The
only
way
to
do
it
I
think
this
also
relates
to
I
think
there's
an
issue
somewhere.
Maybe
you
already
put
it
in
the
thingy
about
being
able
to
promote
a
group
label
upper
level
and
if
you
could
promote
these
group
labels,
so,
like
you
add
a
couple
groups
or
portfolio,
promote
their
groups
and
milestones
up
to
the
portfolio
level,
then
I
think
that
already
helps
a
lot.
B
C
Yeah
that
wasn't
all
worry,
I'll
read
out
through
all
that
and
we'll
see
where
it
fits
in,
but
I
agree
that
I
think
there's
some
thing
that
we
need
to
address
there,
this
next
one's
really
small,
but
it's
been
requested,
and
it
makes
sense,
it's
more
or
less
just
to
be
able
to
get
time
out
and
I
think
this
impacts,
specifically
our
professional
services
group,
but
also
anybody
who's
using
the
try
them
tracking
feature
to
be
able
to
get
like
a
reporting
down
on
an
individual
level.
That
makes
sense.
C
B
He
must
events
like
as
well
I
think
yeah
I
think
we
were
like
this
is
literally
like
this
is
it's
hopefully
I,
hope
I,
don't
regret
saying
this
for
this.
This
seems
like
a
quick
win
because,
like
we
already
store
this
data,
it's
not
like.
We
need
to
go
back
and,
like
start
like
doing
something
different,
we
already
store
this.
B
C
Cool
that
works,
this
other
one
is
kind
of
big
yeah
I,
don't
know
if
it's
bigger
or
not,
but
what
is
there
any
reason
why
we
couldn't
work
towards
having
the
idea
of
multiple
milestones
for
a
issue
and
I
know
you
mentioned
if
we
want
I
think
was
at
you.
If
we
want
to
do
this,
we
need
before
we
do
that.
Do.
B
We
don't
need
to
do
another
thing.
It
was
just
yeah
because
I
was
talking
to
andreas
who's,
the
database
maintainer
about
how
we
filter
labels
right
now,
because
we
match
by
title,
but
we
add
a
label
by
ID
it
makes
and
because
you
can
match
multiple
labels
and
because
it's
quite
denormalized
it
makes
the
resulting
SQL
query
quite
complicated
and
andreas
had
a
suggestion
for
some
denormalization.
That
would
really
help,
especially
as
we
now
don't
have
to
support
my
sequel.
We
can
just
call
Postgres
and.
B
Yes,
so
that's
I
think
that
we
could
get
started
I'd
like
so
that
would
already
be
a
win
for
looking
up
labels.
It
would
make
it
faster,
but
it
would
also
make
it
much
more
composable
on
the
code
side
and
then
we
would
also
need
something
like
this
eventually
for
milestones.
I,
don't
think
it's
a
blocker!
It's
just
that
these
are
related.
We
might
want
to
do.
C
B
So
my
concern
with
doing
this
in
1204
is
that
we
already
have
the
other
requests,
which
is
like
further
down
the
bottom,
which
is
a
higher
priority
about
the
making
the
participants
more
efficient,
so
like
mentioned
uses
so
going
from
a
implicit
subscriptions.
So
you've
you've
got
those
in
the
issue
description
in
the
right
order.
In
the
1204
issue,
description,
the
right
order,
I
would
say-
and
this
isn't
a
blocker
to
doing.
B
C
So
we
talked
about
briefly
this
just
bigger
picture
longer.
Term
I
think
we
need
to
work
towards
having
the
concept
of
teams
be
like
a
first-class
thing,
whether
we
extend
groups
or
make
groups
more
team
friendly,
be
long
term.
We
won't
be
able
to
do
very
effective
capacity
planning
if
and
resource
allocation
like
in
the
product
itself,
unless
there's
a
clear
distinction
of
who's
on
what
team
and
what
time,
how
much
time
do
they
have
and
where
they
allocating
their
their
time
across
projects
or
groups
or
like
whatever
and
then
tracking
against
that
you
know.
C
So
this
is
a
first
proposal.
It
was
I,
think
Kenny
proposed
it
and
it
was
to
add
a
field
team.
It
can
be
assigned
only
to
a
pre
created
group
and
get
lab
future
directions
could
do
interestings
like
auto
assign
teams
based
on
certain
parameters,
so
it
would,
it
would
basically
be
adding
you
know,
there's
just
reference
here,
some
sort
of
like
team
drop
down
to
assign
it
to
a
group
and
then
I
guess
what
are
the
considerations
if
we
were
to
do
this
from
a
technical
standpoint,.
G
B
Think
there
are
a
couple
of
questions
just
sort
of
general
ones,
so
everything
in
an
issue
pretty
much
everything
in
an
issue
right
now
is
visible.
If
you
can
see
the
issue,
so
some
related
issues
might
not
be
visible,
but,
like
things
like
you
know,
the
assignee
or
users
are
always
visible
to
everybody.
Epic's.
If
you
can
see
an
issue
I
believe
you
can
see
an
epic.
If
you
can
see
an
issue,
you
can
certainly
see
its
milestone.
If
you
can
see
an
issue,
you
can
see
its
labels
etc.
B
But
groups
don't
work
that
way,
so
you
know
that's
and
that's
because
they
also
work
for
the
other
cases
that
you've
mentioned
in
your
comment
down
right,
like
we
also
organize
projects
in
a
group.
So
that's
why
you
might
want
to
not
to
be
visible,
but
a
team
if
a
team
was
not
possible
to
be
hidden,
that
would
make
it
a
lot
easier,
I
think
and
it
would
make
it
more
conceptually
aligned
with
a
user
which,
again
all
users
are
always
visible
to
all
other
users.
B
C
B
So
that's
the
wrinkle
where
I
guess
we
could
just
say
you
can
only
use
a
public
group
as
a
team
though
and
like
if
you
make
it
through,
prove
it
and
it's
assigned
as
twenty
issues
as
a
team.
We
unassigned
them
or
something
like
that,
but
yeah
I
think
from
a
product
perspective
as
well.
I,
don't
think
that
sort
of
complexity
that
we
have
around
groups
really
makes
sense
for
what
we
want
to
do
with
teams
like
where
you
can
be
visible
or
not
visible,
depending
on
the
user.
B
C
B
Yeah,
it's
not
clear
to
me
like
what
so
it
says
this
might
also
make
future
searching
boards
and
analytics
at
a
team
level
easier
to
set
up
defaults
for,
but
are
we
saying
that
you
can
filter
by
team
initially
or
not,
because
I
don't
I,
don't
totally
get?
Why
we'd
add
a
field
that
you
can't
do
anything
with
except
to
see
on
the
sidebar,
but
maybe
that
is
the
MVC
I,
don't
know
yeah.
C
That
would
be
like
longer
term
I,
don't
know
in
terms
of
the
MVC,
but
thinking
about
it.
In
our
use
case,
like
let's
say
we
have
our
our
team
and
we're
we're
a
group,
and
then
we
want
to
say,
let's
say
for
our
group:
we
want
to
have
two
week-long,
iterations
and
so
I
maybe
could
configure
some
stuff
in
our
team
that,
like
this,
is
our
default
settings.
So
when
we
go
to
create
an
issue
board,
then
it
breaks
those
things
in
because
it's
a
part
like
that
and
the
team
is
assigned
the
issue
board.
C
That
brings
in
some
of
those
configuration
settings
automatically
and
we'll
create
like
those
kind
of
constructs,
the
two-week
iteration
constructs
as
we
go
and
it's
tied
back
to
the
team
not
to
like
an
arbitrary
issue
board
any.
But
you
can
see
that's
not
it's
kind
of
just
trying
to
open
the
door
for
having
more
tightly
coupled
things,
and
so
in
media.
There's
not
a
ton
of
added
value
for
this.
C
But
what
would
be
one
additional
thing
to
add
on
top
of
this
is
an
NBC
to
add
more
tangible
value
of
like
why
you
would
want
to
add
a
team
to
an
issue.
Can
you
think
of
anything
off
top
right?
If
not
I'm
gonna,
keep
this
invalidation
backlog
and
go
through
the
cycles
with
UX
and
some
customer
discovery,
but.
B
G
G
C
C
B
Is
100%
back
handwork,
it's
already
broken
down
into
probably
one
of
them
as
awhile
since
I
created
them,
but
probably
one
of
the
smallest
possible
issues
but
yeah.
It's
it's
a
reasonable
amount
of
work,
but
it's
not
like
the
priority
from
the
infrastructure
team,
for
this
is
more
like
as
long
as
we're
working
on
it.
That's
fine
like
it's!
If
it's,
if
it
takes
a
while
it
takes
a
while
and
that's
fine
for
them,
so
I
don't
think
we
need
to
I.
C
That
we
didn't
talk
about
labels,
but
I
think
you
know,
I,
don't
know
if
we're
gonna
be
able
to
fit
those
things
in.
We
maybe
can
save
that
for
another
day
and
then
this
other
idea
of
like
what
do
we
need
to
do
to
make
it
so
that
you
can
work
with
an
issue
anywhere
like
from
issue
board
or
from
an
epic
view.
Is
there
any
like
technical
as
I
go
through
and
think
about
playing
for
this
and
validating
it?
C
Okay,
what
about
the
the
one
use
case
you
could
think
of
is
like
if
I
go
and
edit
this
issue
and
I
changed
in
the
labels
and
I
update
the
title
and
then
I
save
it
and
then
I
go
back
is
the
is
in
this.
Let's,
let's
say
this
issue
is
on
the
issue
board
or
was
on
a
epic
view.
Would
those
details
be
updated
or
would
I
have
to
refresh
the
page.
A
C
C
C
A
look
at
that
all
right
cool
anything
else
that
we
need
to
talk
about
for
this
specifically
right
now,
like
I,
think.
The
things
that
have
changed
is
that
we
now
have
until
I
think
the
18th
is
when
the
kickoff
call
is
so
we'll
need
to
decide
all
this
stuff.
We
have
a
little
bit
more
time
to
plan
now
and
I
would
like
to
spend
the
next
little
bit
of
time.
Getting
all
these
things
like
in
order
in
terms
like
a
more
tangible
roadmap
of
how
they
fit
together
and
how
would
they
would
flow?
B
Things
well,
if
you
want
it
to
be
more
continuous
anyway,
right
so
like
as
soon
as
something's
ready,
it
can
go
on
a
12.4
milestone
and
we
can
put
it
in
the
ready
for
development,
States,
I,
guess
like
even
before,
then
how
we
actually
change
to
run
or
we
change
the
day
of
the
kickoff.
Did
we
actually
change
anything
else
like
around
like
because
at
the
moment
we
changed
milestones
on
the
8?
We
didn't
change
that
yet
right,
we
just
changed
the
day
of
the
kickoff
I.
B
B
Kickoff
call
cool
yeah,
so
that's
I,
guess
you
me
and
Donald
Gabe
for
the
ones
for
project
management.
They
talked
about
specifically
the
ones
that
we
think
are
close
to
getting
ready
for
development
and
that
you
think
a
high
impact
to
make
sure
we
get
those
in
first
and
then
sort
of
follow
up
on
the
other
ones.
Once
we've
once
you've
done,
those
I
think
that's
probably
probably
the
best
way
right.
Yep.
C
But
there's
a
lot
of
things
that
are
still
like
in
progress.
That
I
feel
like
have
stalled
over
a
couple
releases
that
maybe
like
now
that
we
did
the
split
there's
gonna,
be
dedicated
resources,
we'll
be
able
to
catch
up
and
get
some
of
those
things
done.
But
let's
work
together
over
the
next
few
days
to
to
like
flesh
out
those
things
and
get
that
on
this
list
as
well
sounds.