►
From YouTube: Plan team weekly - 2019-09-18
Description
Plan team weekly planning
A
So
it
looks
like
we're:
recording
I
have
the
first
point
on
the
agenda.
I
have
some
kind
of
sad
news,
I'm
going
to
be
moving
to
the
security,
so
that
means
a
couple
of
things.
This
is
not
going
to
happen
like
overnight.
I.
Think
I
would
imagine
it's
going
to
take
a
few
months
to
transition
completely,
because
we
have
new
designers
on
the
team
and
new
PMS
and
it'll
just
work
I
think
better
for
everyone.
A
If
it's
a
little
thick
to
slow
things,
so
I'm
thinking
all
the
slowly
ripped
you
can
slowly
ramp
down,
but
we
haven't
decided
on
any
kind
of
transition
plan.
This
also
means
that
we're
going
to
open
a
new
designer
spot
for
the
plan,
team
and
I,
don't
know
whether
I'm
Gabe
and
Keenan,
if
you
have
been
involved
yet
in
hiring,
but
we
do
encourage
the
PMS
to
also
be
a
part
of
the
hiring
process
for
that
stages.
A
Openings
so
maybe
reach
out
to
whoever
is
in
charge
of
that
or
I
can
reach
out.
We
have
Rupert
who's
doing
our
recruiting,
and
so
you
can
be
a
part
of
the
design
interview
process
too.
Does
anyone
have
any
concerns
or
questions
about
that
right
now
and
doesn't
have
to
be
right
now
it
can
be
whatever.
B
My
interview
training
is
in
flight
already,
so
I
can
expedite
that
to
kind
of
be
more
active
and
I.
Think
I
would
also
say
one
thing
I
ask
from
you
is
that
whoever
we
do
bring
in
you
also
get
to
vet
them
to
make
sure
that
they
are
suitable
replacement
for
you,
because
you
know
you're
a
good
judge
of
what
the
team
needs
and
I
think
getting.
Your
sign-off
would
also
be
awesome.
Yeah.
C
Alright,
since
I
have
the
next
item
so
I
have
started
on
food
ingot
lab
for
some
side
projects
and
I
am
wondering
if
we
are
going
to
invest
more
in
mobile
usability,
because
I've
been
using
Trello
for
some
side
projects
and
the
mobile
app
that
they
have
everything
works
smoothly
and
I'm,
happy
mobile
user.
So
I
was
wondering
because
I
found
an
issue
on
boards,
while
you're
using
it
on
mobile
and
I.
Also
noticed
that,
like
horizontal
scrolling,
doesn't
work
very
well
and
there
and
drag
and
drop
is
also
difficult.
D
A
Seen
most
specific
but
I
wonder
if
we
should
see
how
many
users
are
trying
to
access
issue
boards
on
mobile
before
that
before
we
focus
on
that,
we
can
use
Trello
to
as
a
good
judge
and
see
what
they
can
do.
I
honestly
didn't
know
it
was
that
bad
I
can
see
how
drag-and-drop
would
be
weird,
but
the
the
scrolling
horizontally
I
say,
would
work,
but
once
we
get
actual
data
on
that,
maybe
we
can
proceed
yeah.
E
There
I
don't
think
there
was
even
navigation
really
on
boards
until
about
a
month
ago,
when
Martin
and
I
added
it
so
there's
definitely
a
lot
we
could
do
there.
I
think
Annabella
makes
really
good
point
this
like
see,
who
is
using
it,
how
many
people
how
and
then
DC
testing
around
that
and
then
hopefully
start
getting
some
time
to
work
on
it.
F
B
D
Cool
yeah
I've
done
a
little
bit
of
because
in
order
to
access
that
data,
we
would
have
to
use
our
snowplow
metrics,
which
we
have
in
there.
It's
just
not
easily
accessible
through
the
throat
visualization
platform
periscope,
but
I
can
look
into
that.
Also,
okay,
maybe
I'll
chat
with
you
after
you
meet
with
telemetry
and
see
see
what
we
can
do
sounds
good
cool
okay
looks
like
you're
up
next
yeah.
B
So
one
thing
that
I've
noticed
just
is
like
from
an
issue
management
standpoint
that
I
found
kind
of
hard
to
reconcile
is
when
we
split
issues
on
like
technical
boundaries,
instead
of
on
like
customer
user
value
boundaries.
So
I
think
one
point:
there's
a
we're
working
on
the
the
description
diff
and
be
able
to
track
that
and
there's
a
separate
front-end
card,
and
then
there's
separate
backing
card
and
the
backing
cards
really
far.
And
then
the
front
card
is
kind
of
moving
along.
B
But
I
was
just
like
thinking
that
it
makes
sense
to
try
to
do
if
something
is
too
big
and
requires
cross-functional
collaboration
to
like
split
on
feature
surfaces,
to
reduce
the
scope
and
break
the
scope
out
instead
of
like
the
technical
pieces
out.
If
that
makes
sense,
because
that
way,
it's
easier
to
reason
about
how
we
can
ship
smaller
increments
of
user
value
quickly
and
together,
and
then
it
also
makes
it
like
easier.
B
So
you
don't
have
to
like
track
a
bunch
of
different
dependencies
across
a
bunch
of
different
workflow
States,
for
one
like
feature
before
it
can
be.
Ships
at
the
end-user
I
just
wanted
to
get
any
input
it
from
the
team
on
that
before
I
make
a
suggestion
or
propose
a
change
to
our
team
page
on
the
handbook.
D
D
G
It's
just
that
there's
a
seems
to
be
like
it's
like
wider
issue
with
parent
issues
and
sub
issues
like
generally
and
which
can
make
it
look
like
be
hard
to
know.
Looking
at
a
given
issue,
I
think,
like
maybe
probably
most
the
ones
I
seem
to
work
on.
They
have
some
peripheral
issues
around
them
like
they.
Don't
necessarily.
G
B
B
Right
yeah:
this
is
the
second
week
so
I'm
gonna
add
them
to
the
invite
right
now
before
I
forget
that,
but
in
any
event,
he's
gonna
be
working,
I
think
on
some
of
the
like
requirements,
management
piece
which
will
have
to
which
will
deal
with
like
issue
dependencies
and
all
of
those
other
things
and
kind
of
service.
That
I
think
the
other
issue
looked
at
like
is
specifically
for
engineering
managers.
B
Reference
work
because
I
would
like
to
and
as
soon
as
we
have
the
work
in
progress
almost
done,
I
want
to
start
playing
around
with
implementing
work
in
progress
limits
and,
like
I'll,
write
up
the
whole
thing
about
it.
So
everybody
understands
what
they
are
before:
we
do
it
and
we'll
talk
about
it
in
a
weekly
team
meeting
and
have
a
discussion,
but
that
will
only
be
meaningful
if
everybody's
looking
at
the
same
issue,
because
unless
somebody
wants
to
maintain
a
separate
work-in-progress
limit
that
maps
to
the
main
issue
board.
B
G
And
if
you
look
into
like
I
was
reading
some
back
and
some
of
the
issues
where
I
have
been
discussed
before
about
having
some
issues,
and
somebody
had
suggested
that
when
you
have
sub
issues,
the
parent
issue
should
have
a
combined
weight
of
the
sub
issues.
And
if
that
was
the
case,
then
it'd
be
much
much
easier
because
say
like
the
front
end,
people
waited
had
a
different
strategy
towards
waiting.
G
We
were
on
the
backend,
their
combined
weights
that
we
use
the
calculate
velocity
would
have
some
shift
because
they're
not
it's
not
comparing
like
with
like.
Whereas
if
we
combined
everything
into
feature
issues,
then
the
combined
way
it
wouldn't
matter
because
we'd
be
going
on
the
combined
weight.
Every
milestone
of
the
issues.
Yeah.
B
B
D
Yeah
I
think
having
the
sub
task
is
an
important
part
of
that,
because
we
kind
of
do
that
right
now
in
the
issues
that
have
both
front
and
back
and
labels
are
technically
a
combined
front-end
and
back-end
wait.
We
just
don't
have
a
way
of
explicitly
saying
okay
out
of
this
out
of
this
five
wait.
Three
of
it
is
front-end.
Two
of
it
is,
is
back-end.
We
kind
of
do
that
on
the
side
like
I.
B
Yeah
I'll
move
that
issue
into
the
validation
stage,
because
I
have
already
done
some
discovery
around
it
and
some
problem,
validation
and
taking
some
notes,
and
it's
a
widely
requested
feature
already
in
the
wider
community.
So
we'll
see
if
we
can
get
that
prioritized
for
more
than
your
feature.
Releases
and
I
will
drop
that
link
into
the
agenda
momentarily.