►
From YouTube: 2020-09-08 Plan Dogfood Working Group
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).
A
Oh
good
point,
hello,
everybody,
so
what
we
currently
do
is
we
do
that
in
bullet
points,
as
does
engineering
right,
here's
incrementally
how
we're
gonna
build
this
out
and
so
for
design.
It
would
be
here's
how
we're
going
to
incrementally,
validate
or
design
this
so
that
it
can
continue
down
the
flow
like
planning
breakdown,
and
things
like
that.
A
I
currently
don't
know
how
to
use
the
iterations
feature,
even
if
it's
possible
to
use
it
in
a
way
where
design
could
work
in
iteration
or
two
ahead,
and
the
reason
why
it's
it's
difficult
to
imagine
how
is
because
iterations
are
currently
well
they're,
currently
at
the
gitlab
org
level.
A
A
I
don't
think
another
thing
that
makes
it
difficult
is
we
can't
filter,
iteration
view
by
labels,
and
I
think
it's
possible
that
I
want
to
filter
the
iteration
view
by
labels,
because
we
we
can't
use
iterations
at
a
subgroup
level
right
so
and
again,
the
outcome
I
want
is
like
to
have
iterations
that
are
more
validation
and
design
focused,
they're
kind
of
a
separate
track
from
the
delivery
focus
of
those
issues,
because
those
issues
end
up
becoming
a
different
type
of
issue
further
down
the
product
flow.
A
B
There
are
lots
of
nuances
to
unpack
there
in
terms
of
the
iteration
reporting
view
itself,
there's
ways
that
we
can
solve
that,
and
we
have
designs
already
done
for
grouping
issues
by
label
which
is
just
on
our
roadmap.
It's
upcoming
to
solve
the
immediate
pain
point
that
you
mentioned.
The
smallest
thing
that
I
can
think
of
would
be
exposing
the
ability
to
create
lists
of
iterations
on
boards.
B
So
that
way
you
could
have
the
next
few
iterations
as
lists,
and
you
can
scope
the
board
to
like
group
project
management
or
entire
stage,
and
then
the
uxers
could
work
with
the
pms
on
bit
more
or
less
breaking
down
those
bigger
epics
and
sequencing
them
across
iterations,
which
is
actually
one
of
the
core
like
jobs
to
be
done.
That
we
have
in
the
plant
stage,
is
how
you
take
an
epic
and
break
it
down
into,
like
you
know
smaller
sequenceable
iterations,
which
is
a
common
thing
to
do.
A
And
then
that
is
development
time
right,
that's
we
would
need
to
make
some
designs
for
that.
Get
some
lighting
breakdown
to
happen,
get
some
estimation
around
the
issues
to
to
make
that
feature
work,
because
we
currently
don't
have
that
on
boards.
Am
I
right.
B
We
have
the
designs
done
or
it
like
a
95
percent
state,
holly
and
alexis
we're
pairing
on
that,
and
then
we
would
need
to
get
estimates
from
engineering
for
sure
and
like
have
those
issues
but
they're
on
the
eminent
roadmap
anyways,
because
people
won't
adopt
iterations.
Our
customers
want
until
we
have
them
integrated
into
boards.
So,
okay.
B
Lower
hanging
fruit,
I
think,
than
some
of
the
other
things,
because
it's
not
really
introducing
any
new
new
ux
pattern
that
doesn't
preview
exists,
we're
not
other
than
whatever
refactoring
we're
currently
doing
for
boards
for
epic
swim
lanes,
we're
not
adding
any.
I
guess
I
would
say
net
new
logic.
That's
would
require
a
lot
of
engineering
time.
C
Do
you
by
chance
have
the
issue
with
the
designs,
handy,
gabe,
yeah,
and
I'm
wondering
if
that
should
then
be
one
of
the
implemented
improvements
that
we
try
to
take
on
for
iterations,
because
it
sounds
like
this
is
a
just
kind
of
table,
stakes
for
actually
using
iterations
or
actually
dog,
fooding
iterations.
B
Yep,
I'm
sorry
I'm
finding
the
deep
link,
but
we
haven't
put
the
designs
into
the
header
yx.
We're
waiting
for
final.
B
B
B
Mike,
do
you
think
that
if
you
were
able
to
have
a
list
of
the
future
like
in
a
list
for
each
future,
iteration,
it
wouldn't
be
like
ux
getting
their
own
iteration,
but
they'll
be
able
to
work
ahead
of
future
iterations?.
A
B
It
would
work
yeah
follow
on
to
that.
That
would
also
be
helpful
and,
as
a
customer
request
is
adding
reviewers
to
issues
so
where
you
could
almost
like.
Have
a
ux
review
and
the
ux
dri
would
be
sort
of
like
a
merge,
request,
approval
roles,
type
thing
by
adding
that
to
issues
as
well,
which
is
a
customer
request,
and
I've
talked
to
daniel
cruz,
a
little
bit
about
that.
So
I
think
like
if
you
could
have
a
role
of
the
ux
sign
off
on
an
issue
or
approval.
B
C
E
Well,
yeah,
I
think
so
I
mean
we've
ident.
Like
sounds
like
this.
You
know
one
we
just
talked
about
is
sort
of
like
maybe
table
stakes
for
using
iterations
more
broadly,
and
is,
I
think,
a
pretty
large
iteration
on
iterations,
like
maybe
the
lowest
hanging
fruit,
but
still
a
watermelon
size
fruit
rather
than
an
apple
or
something
so
gabe.
Are
there
like.
E
I
mean
there's
like
I
guess
my
question
is
like:
would
we
count
like
small
bug
fixes,
or
you
know
like
what
is
the
like
scope
of
that-
that
kind
of
warrants
success
like
there's?
Certainly,
you
know,
I
think,
small
improvements
that
could
be
made
to
like
the
iterations
report
and
things
like
that.
That
would
be
smaller
than
this.
B
I
think
going
back
to
the
original
purpose,
the
desired
outcomes-
it's
dog
fooding,
so
that
we
can
decrease
cycle
time
and
we
believe
that
iterations
will
help
us
do
that
working
in
smaller
batches,
and
so
I
I
don't
that
we
can
say
the
number
of
improvements
I
I
don't
really
care
how
we
classify
that
I'll
leave
that
up
to
engineering.
B
C
Yeah,
so
I'm
wondering
then,
if
on
the
wording
for
the
kr,
if
we
should
kind
of
move
from
implemented
improvements
to
defined
improvements,
and
maybe
we
can
increase
that
number
from
three
to
five
just
to
jake's
point
we're
at
you
know
we
only
have
a
month
and
a
half
or
so,
and
just
the
thought
of
implementing
a
watermelon
size.
Fruit
like
that
one
like
I
don't
know
how
much
if
we
could
realistically
do
that
and
two
other
improvements
with
the
other
things
we
have
planned
for
thirteen
five
and
thirteen
six.
D
F
Said
john,
like
I
was
just
gonna
say
on
the
warden
of
the
kr
as
well.
They
technically
wouldn't
be
improvements
that
were
discovered
while
dog
food
because
they're
all
all
come
from
customers,
so
we
kind
of
know
them
in
advance.
So
it
also
feels
like
a
shortcut
as
well.
D
So
the
question
is:
if
we
can
also
define
more
kr's
at
the
top
of
it
of
saying,
okay,
we
dog
food,
and
during
that
process
we
define
ten
issues
and
three
we
get
implemented,
so
we
have
two
different
krs
or
if
we
get
ready
for
development.
Five,
that's
totally
up
to
ems,
pms
and
ux
managers
of
telling
me
what
the
numbers
is,
but
I
think
just
having
one
that
simply
says:
okay,
let's
get
three
things
implemented.
B
I
agree
with
that
too,
the
the
biggest
challenge
that
I've
faced
just
playing
planning
that
our
customers
don't
is
being
async
first
and
how
do
you
have
async
iteration
planning
sessions
that
don't
span?
You
know
three
to
four
days,
largely
because
iteration
is
only
a
week
long.
So,
like
you,
you
don't
want
to
have
in
traditional
secrets
meetings.
You
would
have
a
30
minutes
to
an
hour
where
you
look
at
a
board
together
and
you
like
weight
things
and
you
move
things
into
the
next
iteration
or
whatever.
We
can't
do
that
at
gitlab.
B
So
how
should
we
solve
for
that
process?
That's
something
that
would
be
interesting
to
figure
out
how
to
dog
food
that
I
don't
have
a
solution
for,
and
I'm
also
fine
with
just
specifying
ready
for
development
to
a
certain
degree,
because
I
don't
know
how
many
of
these
we
can
even
schedule
in
13-5,
given
our
other
okrs
and
performance
goals
and
pajamas
migrations,
and
you
know
like
just
too
many
competing
priorities.
C
Yeah,
so
what
if,
instead
of
focusing
on
like
improvements
to
iterations
the
feature
we
focus
on
the
dog
fooding
aspect,
so
something
like
that
would
be
aspirational,
but
100
of
issues
that
go
into
13,
5
or
13
6
have
an
iteration
tied
to
it
or
we
determine
what
our
iteration
velocity
is
by
the
I
don't
know.
C
Not
even
are
we
in
iteration
6,
I
think
right
now
I
like
iteration
10,
and
maybe
we
could
do
that
earlier
and
then
we
can
also
define
another
kr
to
be
implement
something
determined
from
one
of
the
earlier.
G
Krs
I
like
that,
that's
along
the
lines
of
what
I
was,
I
think
all
the
plan
pms
were
proposing
for
the
product
department
krs.
It's
basically
like
adopt
it
start
using
it.
We
have
five
iterations
left
before
the
end
of
the
quarter
so
start
using
it
measure
our
our
throughput
or
velocity
and
then
ideally
come
out
with
prioritize
set
of
improvements.
D
Sounds
like
a
good
kr
for
product,
then
I'm
coming
back
to
development,
let's,
let's
simply
say:
okay,
we
we
enable
that
part
and
make
this
as
a
kr,
so
that
we
have
something.
I
think
it
would
be
very
hard
to
to
keep
to
one
pr
for
everyone,
but
simply
that
justin
you
go
ahead
and
define
that
kr
for
product
and
we
go
ahead
and
define
basically
the
kr,
especially
around
the
one
thing
that
it
seems
to
be
like
the
door
opener
to
really
using
it
that
we
basically
implemented
and
get
it
implemented
there.
A
It
sounds
like
ux
could
also
dog
food
if
we
made
some
iterations
in
the
current
iteration
list
made
some
iterations
that
are
like
out
of
out
ahead
right.
A
A
B
You're,
immediate
yeah
that
would
work
it'll,
be
super
painful
to
like
manage
that.
That
would
I
mean
like
getting
issues
added
to
it
and
stuff
like
that.
But
yes,
it's
like
it's
possible,
but.
E
E
E
G
Of
product
prioritizes
like
a
an
investigation
issue
in
136
to
start
the
work,
we
don't
commit
to
shipping
it
in
13-6.
G
If
we're
scared
of
it
now
and
we
commit
to
a
poc
or
something
like
that
in
13-6.
D
If
we
work
in
good
iterations,
we
anyhow
can
at
least
ship
what
we
get
done
until
the
end
and
that's
also
all
the
target
of
the
ocr.
So
I
think
yeah
dog
fooding
is
painful
and
scary
and
all
the
other
things
at
the
same
time
so
yeah.
I
would
rather
say:
let's,
let's
target
getting
a
dean
than
trying
to
drive
an
kr,
that's
simply
around
the
plc
so
that
we
could
hit,
but
rather
get
not
something
valuable
into
the
product.
D
At
the
same
time,
and
perhaps
along
those
lines
we
we
are
able
to
to
cut
it
into
smaller
pieces
so
that
we
get
80
delivered
anyhow
yeah,
so
I
mean
I
mean.
C
Sorry
for
cutting
you
often,
my
main
fear
with
this
is-
is
on
the
unknown
and
just
looking
through
like
what
we
have
planned
for
thirteen
five
it's
fairly
and
then
also
what
we
still
have
left
in
13
for
like
unless
we
drop
everything-
and
this
is
the
number
one
priority
for
13.6
yeah.
My
fear
is
just
without
doing
that.
C
I
think
that
would
be
a
great,
a
great
use
case
of
of
dog
fooding,
so
I
think
it'll
be
aspirational
if
we
define
the
kr
as
fully
implementing
this
feature
by
13.6.
C
G
Gabe,
I
want
to
ask
you:
do
you
feel
comfortable
with
that
from
a
prioritization
perspective,
because
it's
sort
of
we're
making
a
global
decision
here
as
a
group
to
prioritize
something
and
you're
the
dri
for
prioritization
for
the
project
management
group?
So
I
want
to
make
sure
you're
comfortable
with
this.
Given
all
the
other
priorities
and
things
you
don't
have
to
answer
now.
Also
you
can
come
back
to
canada.
B
No,
I'm
not
comfortable
largely
because
I
want
to
support
my
engineering
and
ux
okrs
as
well,
which
require
a
large
portion
of
time
and
engineering
time,
basically
so
in
the
perfect
world,
if
we
had
unlimited
resources,
absolutely
okay
with
prioritizing
this,
if
I
knew
that
those
other
things
wouldn't
slip,
so
this
goes
up
to
management,
which
would
you
work
prioritize,
as
as
leadership
in
the
company
you
know,
is
performance
more
important
than
dog
footing,
okrs
or
iterations?
B
That's
that's
where
I
struggle.
You
know.
G
Yeah
yeah,
my
broader
concern
here
is
that
you
mentioned
earlier
gabe.
We
have
performance
improvements,
we
haven't
yet
started,
I'm
sorry
if
I'm
I'm
misspeaking
there
and
then
pajamas
components
to
implement
that.
I
don't
also
don't
think
we've
started
yet
and
then
a
bunch
of
work
like
donald
was
saying
earlier.
D
D
H
Yeah
well,
of
course,
nothing's
nothing's
uncomplicated,
when
we're
facing
this
scenario,
so
the
concern
we
I
would
have
with
that
is
especially
on
the
portfolio
certified
since
we
are
sharing
resources
is
that
we
are
either
moving
category
maturity,
nbc's
forward
on
the
certify
side.
I
don't
know
if
mark's
on,
I
can't
see
you
can
talk
to
that.
H
But
on
the
other
side,
you
know
in
portfolio
management
we're
trying
to
close
feature
gaps
that
directly
tie
to
a
large
amount
of
iacb
between
now
and
next
year,
and
so
again,
like
gabe
was
saying
this
gets
into
a
conversation
where
we
have
competing
priorities
that
have
all
been
put
into
place
at
the
same
time
and
now
we're
in
a
situation
where
we
have
to
basically
say
like
hey,
which
one
do
we
care
about
the
most
as
a
company,
and
we
get
varying
answers
to
that.
Sometimes,
and
so
it's
difficult.
G
You
know
stepping
back
is
there
a
reason
why
we
couldn't
say
for
this
quarter
for
this
okr?
It's
about
adoption
like
we
just
start
using
we're
not
using
iterations.
Now
we
just
start
using
them
and
then
in
a
follow-on
quarter.
So
q4
is
more
about
prioritization
of
improvements
based
on
the
findings
we
have
and
granted.
We
know.
Clearly,
we've
talked
about
it.
We
know
some
of
the
obvious
ones
that
we
need
to
work
on,
that
we
could
consider
prioritizing
in
q4,
but
what
about
sequencing
it?
That
way?
G
It
just
feels
like
there's
going
to
be
a
lot
of
tension,
a
lot
of
pressure
and
a
lot
of
stress
added.
If
we
try
and
commit
to
prioritizing
something
now
where
I
think
we
can
get
some
benefit
and
value
in
five
iterations
and
a
clear
understanding
of
what
we
should
prioritize
in
the
sequence
of
those
things
and
then
just
commit
to
that.
B
Q4,
I
think
we
need
to
leave.
We
could
talk
about
this,
some
more
but
yeah
that
just
puts
icb
back
or
more
or
less
new
customers
in
my
mouth
metrics
increasing,
since
this
is
the
stuff
I
need
to
do
anyways
for
that.
So
it's
like
a
it's
a
no-win
situation.
I
feel
like.