►
From YouTube: Plan stage weekly meeting - 2019-08-21
A
C
D
D
E
D
B
Cool
welcome,
Kenan,
really
glad
that
you
joined
just
a
super
minor
thing.
Gabe.
The
group
is
portfolio
management
and
the
thingy
within
that
the
category
is
agile
portfolio
management,
because
they're
not
allowed
to
have
the
same
names.
That's
one
of
the
rules
called
one's
got
a
Jalloh
from
so
it's
it's!
It's!
Okay!
That's
that's
gaming!
The
system
right
there
speaking
of
names,
so
team
planning.
B
C
Sure
so
the
I
linked
to
the
original
issue
where
this
was
being
discussed,
but
the
gist
is
we
were
working
on
the
category
vision
for
project
management
and
it
was
difficult
to
nail
down
the
maturity
level
and
what
we
need
to
do
and
what
the
next
steps
were
so
and
trying
to
bring
clarity
to
that.
It
made
more
sense
to
just
more
or
less
like
issue
tracking
became
a
new
category.
That's
going
to
take
over
a
lot
of
stuff
that
was
technically
in
project
management
and
then
project
management's,
the
group
name.
C
B
Makes
sense
just
a
note
on
that
as
well.
I've
noticed
some
people
adding
issues
that
aren't
related
to
project
management
or
team
planning
to
that
people
and
I.
Think
the
confusion
is
that
sometimes
people
think
I
want
to
manage
you
get
lab
projects.
So
that's
project
management,
but
that's
not
like
project
management
as
a
discipline.
That's
like
managing
a
get
my
project
so
like
sometimes
you'll
see
that
when
it
should
probably
be
somewhere
and
manage
or
something
so
just
so,
you
know
Gabe.
You
wanted
to
talk
about
workflow
labels,
yeah.
C
So
this
past
week,
things
found
when
you're
out
we
were
using
a
set
of
generic
validate
labels
that
were
trying
to
align
with
the
product
development
flow
and
they
got
hijacked
by
a
specific
group,
I
believe
fulfillment
and
like
we
can
either
go
through
and
create
all
of
our
own
labels.
For
you
know
our
specific
stage
that
are
plain
related.
C
That
would
help
groom,
are
kind
of
different
lists
for
us
automatically
and
I
just
wanted
to
have
a
general
discussion
around
how
we
wanted
to
approach
that
the
ideal
would
be
to
hopefully
have
some
set
of
single
scope,
labels
that
would
work
across
all
of
our
different
lists
and
like
workflow
stages
and
then
also
some
tools
that
would
help
us
keep
those
labels
up
to
date,
because
not
everybody
looks
at
the
Kanban
board
and
drag
stuff
around,
and
so
like.
That's
fine,
but
I
also
notice
Chadha.
C
C
C
We
can
create
generic
scope
labels
I'm
fine,
doing
that.
I'll
just
create
separate
ones
and
like
say
don't
you
know
change
these
I
talked
to
the
triage
people
already
and
asked
them
like
what
the
deal
was
and
if
there's
any
policies
around
changing
labels
and
there's
not
an
explicit
policy
right
now,
get
laugh
about
who
can
change
labels
and
who
can't
technically.
B
I
think
that's
probably
the
smallest
initial
change
and
then,
if
that's
still
not
working,
we
can.
We
can
try
something
else.
Basically,
so
I'm
guessing
fulfillment
made
them
scoped
because
they
wanted
to
have
only
one
of
the
fulfillment
like
validate
fulfillment.
Sorry,
problem
validation,
fulfillment
solution,
validation,
fulfillment,
whatever
labels
on
an
issue
is
that
right,
I'm.
C
B
I
agree:
yeah
I
think
I
think
that
this
is
like
the
small,
primitive
thing
right:
we've
promoted
these
small
primitives
and
then
it's
like
you
could
assemble
them
in
a
bunch
of
different
ways.
So,
like
the
way
that
works
for
us
might
not
work
for
fulfillment
or
whatever
so
I
think
I
think
out
of
all
suggestions.
The
the
boring
solution
to
guests
like
unblocked
they're.
G
I
C
C
C
Next
item:
as
of
12.2,
there's
a
new
release
post
contribution
process,
we're
trying
to
do
it
more
changelog
style
so,
like
all
the
work,
doesn't
stack
up
the
day
or
two
before
the
release
post,
and
so
with
that
we
have
to
submit
a
merge
request
to
the
double
WW
repo,
with
our
changes
and
there's
like
a
merge
request
template
now
that
lists
out
what
you
need
to
do
and
like
what
you
need
to
include
and
I'm
happy
to
do.
All
those.
C
But
like
is
what
sort
of
process
do
we
want
to
like
have
in
place
to
ensure
that
we
kind
of
do
that
is
part
of
the
dun
dun
completion
criteria
of
the
features
that
are
going
to
go,
and
it
really
supposed
like
when
we
merge
that.
Mr,
so
we
don't
wait
till
the
last
day
to
do
it.
We
kind
of
do
it
continuously.
As
we
merge
completed,
features.
B
So
we've
got
Martin
threats
and
Alexandra
and
Michelle
I
just
noticed
as
well
on
the
call
who
are
all
like
individual
engineers.
Sort
of
working
on
features,
I've
also
got
Scott,
but
Scott's
obviously
recently
joined.
So
any
of
you
have
any
thoughts
on
like
what
makes
most
sense
from
a
workflow
perspective
for
getting
those
items
added.
E
So
if
both
are
working
progress
and
both
are
in
development,
I
suppose
of
workflow
labels,
then
it
kind
of
makes
it
difficult
for
anyone
to
visualize
what
exactly
is
being
actively
developed
upon
and
what
is
going
side
by
side.
So
those
are
the
only
problems
but
I
think
I'm
all-in
for
adding
workflow
labels,
so
that
makes
sense
can.
B
B
C
Think
that
would
be
fine
to
start
and,
like
I
said
I,
don't
mind
doing
the
DMR's
for
the
futures
to
get
them
into
their
release
post
and
filling
out
all
the
content.
It's
just
like.
Sometimes
it's
difficult
for
me
to
see
everything
that
is
done
and
but
I
think
that's
just
still
may
get
used
to
the
workflow
that
we
have
and
I
kind
of
keep
up
with
everything.
So
manual
boring
is
great
for
a
first
step.
If.
C
E
C
Through
that
list,
maybe
like
every
few
days
and
double
check,
I
think
that
would
be
fine
I
think.
Maybe
we
use
the
feature
label
too.
So
maybe
if
we
just
have
a
feature
label,
that
will
be
a
good
reminder
to
double
check
on
that
I'm
still
trying
to
get
a
good
feel
for
what
to
include
and
they're
really
supposed
to
and
whatnot.
So,
oh
I'm,
fine
doing
that
and
just
I
guess
I'm
bringing
this
up
to
help
remind
me
if
I
don't
catch
something
you
know.
C
C
B
Have
adjust
using
the
board's
priorities,
but
then
that
does
mean
that
if
you
look
at
like
some
of
the
chants
that
say
like
number
of
deliverables
shift,
0
number
of
deliverables
missed
zero.
So
it's
not
sort
of
assumptions
in
some
of
the
charts
that
the
engineering
productivity
team
we've
created
that
don't
really
match
with
how
we've
been
working
but
I
think
fine
to
add
that
back.
If
we
want
to
as
well
and.
C
I,
don't
have
a
strong
preference
I
think
the
the
way
we're
doing
really
explaining
is
slowly
shifting
to
be
more
continuous
I
know,
there's
a
big
conversation
going
on
I'm
not
participating,
but
I
am
aware
of
trying
to
move
things
to
have
like
kind
of
more
continuous
model
where
the
release
post
is
becomes
just
a
function
of
what
is
done
in
a
given
four
weeks.
Man,
instead
of
like
doing
all
this
crazy
upfront
planning
and
pushing
at
the
last
minute,
so
we'll
see
how
that
goes.
B
Good
to
me,
okay,
so
yeah,
we
could
start
with
doing
this
manually.
Another
thing
we
could
do
is
actually
like.
We
get
these
triage
packages
through
the
triage
ops
thing,
and
we
could
also
like
see
about
creating
those
for
like
things
that
are
in
workflow
verification
or
were
closed
during
the
last
week,
for
people
to
like
make
sure
that
the
released
posts
and
stuff
is
updated,
but
that
would
be
in
the
future
if
we
figure
out
that
doing
this
weekly
works
or
whatever,
okay.
C
Sounds
good
next,
yeah
and
I
just
wanted
to
know.
Last
week
you
weren't
here
Sean
and
I,
don't
think
Donald
was,
and
there
wasn't
a
ton
to
talk
about.
So
it
didn't
last
that
long,
which
is
fine,
but
is
there
anything
that
we
want
to
do
or
does
anybody
have
any
suggestions
about
a
little
bit
of
structure
or
flow
to
like
this
planning
meeting
where
it's
something
that
helps
us
all
stay
on
the
same
page
and
get
aligned
with
what
we're
working
on
or
where
we're
going
so
I
just
bring
this
up.
C
I
come
from
doing
weekly
iterations
or
we
do
release
planet
aired
like
planning
meetings
once
a
week
to
talk
about
what
we're
getting
done
as
a
team
and
what
we
want
to
commit
to
I
didn't
know
something
like
that
would
be
helpful
to
run
through
the
board,
or
maybe
we
like
it.
This
way,
I
just
kind
of
want
to
open
up
and
see
if
anybody
have
any
ideas
or
input
I,
don't.
B
Want
to
take
over
the
conversation
here,
I
know
it's
been
you
and
me
talking
a
lot
so
far
on
this
call,
but
I
do
have
a
couple
of
things.
So,
first
of
all,
I
think
the
structure
and
flow
would
be
nice
to
consider
like
how
we
can
marry
like
having
a
call
with
asynchronous
conversations,
because,
obviously
not
everybody
on
the
team
is
in
a
time
zone
where
they
can
make
this
call
or
any
call
like
you
know,
there's
not
there's
not
a
call
where
we
can
have
everybody
in
the
group
join.
B
Also
when
we
slip
the
groups
they,
like
you
know,
John
joins
and
Keenan's
just
joined
as
well.
We
decided
to
keep
this
as
one
meeting,
but
we
might
decide
that
we
want
separate
meetings
as
well,
Mike,
obviously
for
people
like
Annabelle
and
Donald,
they
would
still
have
to
attend
both,
but
for
those
of
us
who
are
just
focused
on
team
planning
or
portfolio
sorry,
project
management
or
portfolio
management,
you
know
that
might
be
a
good
way
to
scope
it
down
too.
B
So
those
are
just
some
considerations,
I'd
like
to
add
there,
but
I'm
very
curious
to
see
what
other
people
think
as
well
I.
Also
like
the
recent
change
you
made
to
the
company
core,
where
it
was
in
sort
of
sections
so,
like
you
know,
it
was
grouped
by
not
who
put
something
on
the
agenda
and
what
order
but
groups
sort
of
by
topic.
Like
you
know,
these
are
announcements.
These
are
other
updates.
You
know
you
could
you
could
add
more
sections
for
stuff
like
that
as
well.
I
Yeah
I
don't
have
any
specific
suggestions
yeah,
because
I
don't
have
enough
context
around
it
like
like
every
one
of
these
have
been
too
has
been
quite
different.
That's
only
two
so
far,
but
I
did
watch
the
other
ones
before
he
joined
and
yeah
look
I,
don't
I'll
keep
an
eye
out
for
ways
we
could
add
structure
to
it
like
in
terms
of
like
things
that
we
could
do.
That
would
be
helpful,
especially
probably
for
Keenan
and
myself
as
well,
but
I
don't
have
anything
off
the
top.
My
head.
F
Yeah
would
also
like
to
hear
from
like
the
grater
came
to
it
cuz.
This
should
be
mostly
for
the
benefit
of
the
members
of
both
project
management
and
portfolio
management
groups.
So
anyone
else
like
what
would
you
all
like
to
see
out
of
this
meeting?
I
know
we
actually
had
talked
about
somehow
getting
demos
in
a
meeting.
F
I,
don't
know
if
if
a
synchronous
meeting
like
this
is
the
best
platform
for
those
demos,
maybe
if
we
could
I
don't
know,
add
some
videos
or
recordings
and
have
some
time
which
I
think
that
would
be
helpful
or
that
anyone
else
have
any
other
thoughts
on
what
you
would
like
to
see.
Out
of
this
weekly
mean
I.
B
Gabe
actually
wrote
out
a
narrative
for
the
next
three
or
four
releases
somewhere
I,
don't
know
if
you
can
find
that
quicker
than
I
can
cave,
but
I
thought
that
was
very
useful
to
way
of
sort
of
thinking
about,
like
what
wait
for
me
to
understand
what
you're
thinking
about
like
going
forward
is
like
top
priorities.
I.
C
I
I
think
that
actually
is
we
split.
The
team
and
engineers
start
to
work
on
different
things.
It
might
be
good
job
form
where
we
do
demo
some
stuff.
The
thing
is
like
it's
very
hard
to
think
of
anything
that
can't
be
done
better,
asynchronous,
very
synchronously
than
in
the
meaning
like
for
them,
but
there
may
be
some
value
in
that
because
after
a
couple
of
releases
like
if
we
split
the
team
like
automatically,
then
it's
quite
possible
people
on
portfolio
management
won't
have
an
idea
of
what's
been
going
on,
and
project
management
and
vice-versa.
B
Yeah
I
think
that's
a
reason.
We
decided
to
like
not
split
any
meetings
initially
as
well,
because
we
figured
which
we'd
wait
till
a
point
where
they
we
felt
like
we
needed
to
split
them,
but
we
wanted
to
like
default
to
just
having
the
the
broader
conversation
as
much
as
possible
and
keeping
people
in
the
loop
as
much
as
possible.
B
F
F
Sorry,
real,
quick
Shawn.
Maybe
we
continue
this
discussion
in
and
m/r
I
think
we
have
somewhere
defining
that
we
have
weekly
meetings.
Maybe
we
can
all,
especially
for
the
people
that
aren't
here
right
now,
but
if
we
can
comment
on
ideas
or
thoughts,
the
structure
and
additions
to
the
to
this
meeting
in
NMR
I
think
that'd
be
helpful.
Yeah.
B
K
All
right
so
Alexandra
and
I
found
a
possible
pain
point
of
confusion.
Point
regarding
ordering
specifically
ordering
by
priority.
So
I
wanted
to
see
like
get
your
feedback
and
see
what
the
general
consensus
is
like
what
you
expect
to
see
out
of
the
app
basically
on
Caleb
comm,
if
you
or
there
issues
by
priority
it
gives
you
a
higher
priority.
First
lower
priority
later
and
indeterminate
priority
lasts.
K
So
the
question
is:
oh
and
you
can't
flip
the
order,
so
you
can't
get
low
priority
first
I'll
talk
about
is
so
the
question
is:
do
we
call
this
a
descending
or
a
sudden,
the
people
there
for
the
purposes
of
an
API
that
allows
you
to
sort
by
priority
and
doesn't
make
sense
to
expose
both
orders
in
the
public
API?
This
is
a
thing,
that's
difficult
to
change
in
the
future.
Once
we
ship
it.
B
B
K
The
other
thing
is
we
befall
to
descending
order
and
we
default
and
highest
priority
first.
However,
the
way
it
like,
if
we
put
it
in
if
we
call
the
default
order,
ascending
so
like
by
ascending
index
like
priority
five,
is
higher
than
zero
and
you
don't
specify
the
sending
or
descending
it
will
default
to
the
other
way.
If
that
makes
sense,
I'm
pretty
sure,
like
that's
I,
if
you're
confused,
you
can
see
how
it'd
be
confusing
for
new
users
as
well.
H
There
are
like
it
also
might
make
sense
for
different
order
options
to
have
different
defaults
for
the
direction
because,
like
for
priority
you'd
want
it
default
to
be
ascending,
for
instance,
and
then
for
weight.
You
might
want
to
default
to
be
descending
yeah.
So
and
again,
all
of
these
changes
would
add
changes
to
the
user.
If
we
do
change
it
so
like
that,
the
default
behaviour
might
change.
So
that's
something
to
really
consider
before
actually
making
this
change,
because
if
we
don't
want
it
to
have
users
break
their
workflows
that
over
they
kind
of
exist.
F
F
If
you
wants
to
give
the
the
reasons
for
leaving
it's
just
an
opportunity
that
he
couldn't
couldn't
pass
up,
like
I
said
going
to
going
to
miss
him,
even
though
you've
only
been
here
for
a
few
months,
you've
already
had
a
huge
impact
on
the
only
the
front-end
team,
not
only
the
plan
stage,
but
I
get
lab.
So
let
me
see
and
I'll
let
you
say
something
if
you
would
like
to
work.
Yeah.
K
L
Yeah,
so
on
my
side,
just
heads
up
since
one
of
the
okay
art
of
the
quality
departments
is
to
cover
some
task
gaps
in
enterprise
features
I'm
doing
my
part
with
the
planned
features,
and
there
is
a
board
available
that
I
linked
in
the
document.
If
you,
if
you
want
to
to
see
what
we
have
planned,
it's
there
in
the
board,
there
are
some
issues
that
have
been
completed
there,
I'm
working
on
a
specific
issue
right
now
for
milestone
board
lists,
and
there
are
other
come
others,
other
issues
already
planned
for
for
the
next
iterations.
E
Yes,
so
while
this
issue
is
more
targeted
towards
animal,
but
I
just
wanted
and
I
team's
eyes
on
this,
so
with
the
dragon
drop
with
the
complexities
that
we
face,
we
decided
to
start
with
an
MVC
we're
in
the
tree.
Instead
of
allowing
issues
to
be
reordered,
you
would
just
allow
epics
to
be
reordered
in
the
tree,
but
in
the
design
we
are
deciding
to
show
issues
alongside
epics.
So
my
question
is
that
would
it
make
sense
from
a
user's
perspective,
to
have
epics
being
the
reorder
level
while
issues
being
there
as
it
is?
E
And
then
how
does
the
behavior
affect
the
rest
of
the
tree
like,
for
example,
we
are
showing
both
root
issues
as
well
as
root
epics
in
the
same
tree
in
the
root
itself.
So
if
we
have
five
items
of
both,
then
user
is
able
to
reorder
only
five
of
those
items
and
how
does
it
affect
the
order
of
other
items
like
I?
Had
now
some
general
confusion
around
the
us
so
just
wanted
to
know
the
thoughts
of
everyone
who
were
involved
in
the
conversation.
M
E
Yes,
so
I've
currently
linked
the
issue
in
the
agenda,
which
includes
the
UX
proposal
that
we
decided
where
we
would
ship
the
tree
and
the
road
map
and
the
top
of
the
page,
while
leaving
the
discussion
part
at
the
bottom
of
the
page.
But
the
tree
design
itself
remains
as
it
is.
We
would
have
both
issues
and
epochs
are
of
the
same
free
and
the
Ammar
that
we
had
open
when
we
started
working
on
packet
drop.
E
M
My
first
impression
is
is
make
sure
they're
still
on
the
same
list,
because
separating
them
will
just
be
kind
of
what
we
already
have
I'm
wondering
the
the
smallest
way
to
do
this.
If
this
is
just
a
first
iteration
and
eventually,
we
will
be
able
to
get
the
full
interest
first
dragging
and
dropping.
We
could
only
to
look
at
this
similar
and
think
of
a
solutions
that
off
the
top
of
my
head.
We
could
do
something
like
when
you're
in
finder
and
you're
dragging
files
around.
You
know
how
the
cursor
turns
into
that.
E
Because
the
the
UX
infusion
I
had
around
this
a
behavior
was
that
imagine
a
list
where
we
have
five
issues
at
the
top
of
the
list
followed
by
fire
picks
at
bottom,
and
we
are
saying
that
we
will
allow
reordering
all
the
epics
and,
if
user
grabs
one
of
those
epics
and
tries
to
order
it
between
the
two
existing
issues.
Then
technically
we
are
moving
around
issues
as
well,
because
we
are
trying
to
drop
an
epoch
between
two
issues,
which
is
invalid,
because
we
don't
want
issues
to
be
moving
around.
E
M
E
So
what
you're
saying
is
that
they
remain
in
the
same
list
just
that
they
cannot
enter
in
each
other's
territory
while
the
ordering
right,
then
there
me,
but
still
there
won't
be
any
visual
separation.
Then
how
would
users
know
that
these
items
are
the
orderable
within
this,
because
there
is
no
division
between
the
two,
at
least
from
visual
point
of
view,
right.
M
E
E
It
currently
allows
for
reordering
across
the
list
just
that
when
you
reload
the
page,
your
order
goes
away
because
it
is
parented
okay,
so
you
can
try
it
out
how
reordering
works
correctly,
because
we
are
allowing
full
reorder
so
for
death,
okay,
yeah
and
also
one
more
thing
to
add
there.
In
the
original
scope
of
drag
and
drop,
we
decided
to
allow
parent-child
relationships
to
be
altered
as
well
from
the
tree.
E
So,
for
example,
if
user
is
trying
to
drag
an
issue
or
an
epic
on
to
another
epic,
that
would
mean
that
we
are
changing
the
relationship
with
that
best
friend,
epic,
to
the
entities
that
we
are
trying,
in
fact,
so
now
that
we
are
deciding
that
we
won't
allow
reordering
between
each
other,
they
will
reorder
only
amongst
themselves.
Then
do
we
still
cover
the
parent
child
or
updates
from
Fraggle
Rock.
M
M
E
So
the
amount
that
I
willing
to
it
has
related
issue
in
which
we
are
discussing
the
original
idea
of
how
taiga
drop
leads
to
work.
It
has
all
the
points
mentioned
there
like.
We
want
to
cover
parent-child
updates
as
or
like.
If
user
tries
to
drag
an
epic
within
or
inside
another
sibling
parent,
then
it
would
lead
to
changing
the
parent
epic
for
that
particular
item
to
the
one
we
where
we
locked
it.
E
So
that
means
that
basically
means
like
if
you
are
using
finder
and
if
you
are
trying
to
drag
a
file
into
a
folder,
then
that
final
goes
inside
of
that
foot.
So
that's
how
we
change
the
parent
of
that
file
and
we
want
similar
behavior
for
a
picture
issues
as
well
and
user
tries
to
drag
items
into
each
other.