►
From YouTube: ENG/UX Progressive Delivery meeting 2020-07-21
Description
Meeting to improve alignment between Engineering and UX for progressive Delivery
A
A
B
A
A
C
A
Awesome
thanks
for
that,
then
I
have
the
opposing
thing
before
we
go
in
a
little
bit
more
processing
questions.
There
is
this
follow-up
from
advocates
actually
more
for
andrew.
I
saw
this
issue
as
like.
I
do
not
know
what
is
going
on.
What
is
this,
so
I
thought
it
might
speed
up
us
a
little
bit
if
I
just
ask,
but
then
I'll
I'll
shoot
him
a
message
in
slack
or
something
and
you
can
have
a
quick,
101
or
I'll.
Just
read
the
description
about
it.
A
A
I
have
created
this
page
specifically
from
like
looking
at
those
processes
from
ux
point
of
view
and
to
have
like
I
navigate
throughout
gitlab
handbook
and
issues
and
the
project
through
these
links,
it's
nice
for
me
to
have,
but
I
also
detail
things
like
how
we're
working
with
jobs
to
be
done.
How
we're
doing
product
planning
like
I
know,
there's
all
kind
of
detailed
details
that
I
am
gathering
for
myself
and
the
handbook
page
for
the
engineering
team
is
one
of
the
things
I
really
need
to
dive
into
still.
A
But
it's
like
a
huge
document,
even
if
it's
just
for
progressive
delivery
with
a
lot
of
information
in
there
and
discussing
with
ori.
Earlier
today,
I
spoke
out
that
I
I'm
like
this
is
based
not
on
facts.
It's
just
a
feeling
that
I'm
not
sure
how
engineering
always
decides
on
what
to
work
on
is
the
planning
issue
the
funnel,
for
what
engineering
decides
to
work
on
or
is
there
additional
methods
that
engineers
and
engineering
managers
decide
on
what
their
team
will
work
on
for
any
given
milestone?
D
B
C
B
I
don't
know
that's
the
main
rule
of
thumbs
in
the
team,
as
far
as
I
know,
but
chase
would
come
from
that.
But
I
know
at
the
moment
like
I
started
at
p2
as
part
of
13.2,
and
so
I'm
trying
to
to
move
that,
for
you
know
to
to
work
on
that
in
priority,
even
though
it's
a
p2,
because
I
already
started
work
so
to
me
that
takes
precedence
over
like
the
new
p1.
I'm.
D
Yeah
anything
for
that's
in
progress.
That's
from
the
previous
milestone,
I
think,
has
we
should
like
wrap
whatever
we're
doing
up.
We
shouldn't
drop
like
we
shouldn't
leave
like
work,
sort
of
half
hanging.
I
think
sort
of
finish
what
you're
doing
before
you
pick
up
something
new,
even
if
it's
a
lower
priority
from
the
previous
milestone.
It's
still
like
still
makes
sense
to
me
to
continue
on
to
do
that
and
then
do
to
go
through
and
find
a
p1
to
pull
from
the
current
milestone
in
my
head.
D
They
all
should
have
some
kind
of
prioritization
label
on
them,
even
if
they're,
not
this,
express,
they
called
out
in
the
in
those
other
other
like
high
priority,
deliverable
type
buckets
like
a
release
p1,
they
may
have
like
release
p3
on
them
and
that's
not
necessarily
listed
there.
But,
like
you
know
things
like
bug,
fists
bug
fixes.
You
know,
polish,
all
those
kinds
of
things
might
end
up
in
the
p3,
depending
on
how
up,
depending
on
the
bug,
triage
labels
right
like
p2s2,.
A
A
Interesting
interesting
thanks
for
sharing
that
I
I
do
want
to
know.
I
would
do
want
to.
Let
know
that
for
progress,
delivery
and
actually
also
ci,
but
as
I'm
managing
progress,
delivery
from
product
design,
perspective,
ux,
depth
and
ui
polish
have
become
part
of
charging
efforts.
So
in
that
try
issue
report
issues
that
are
generated
every
week.
A
We
do
list
the
ones
that
have
not
yet
received
like
a
milestone,
either
backlog
or
something
more
decisive,
and
my
my
take
on
that
is
that
I
try
to
as
soon
as
I
can
find
the
time
for
them
every
so
many
so
many
days
give
every
ux
that
ui
polish
issue
a
label
at
least
severity
label,
priority
label
I'll
leave
up
to
to,
or
it's
to
say,
like
hey
this
is
you
know
absolute
priority
regardless
of
severity.
Yes
or
no,
I
know
I'm
just
I'm
just.
I
was
just
wondering
about
that.
A
A
How
often
does
it
happen
that
engineering
takes
on
or
is
bringing
in
additional
issues
into
that
milestone?
That
weren't
like
scheduled
for
so
much
are
those
mostly
scoped
off
issues
that
are
brought
in,
or
is
that
not
happening
at
all?
Just
I'm?
What
I'm
trying
to
get
out
of
this
is
that
I'm
trying
to
see
how
things
go
into
the
milestone,
and
you
know
I
need
to
get
as
clear
an
overview
of
what
happens
within
a
milestone
as
I
can
so
that's
why.
A
D
I
think
we've
had
that
happen
a
few
times
since
I've
been
here
the
when
things
do
show
up
into
the
milestone
that
weren't
necessarily
planned
for
it.
It's
because
something
some
prioritization
thing
has
has
changed,
or
we
like
say
for
feature
flags.
For
instance,
like
we
went
down
a
road
and
we
realized
that
the
timing
is
not
right,
and
so
we
had
to
quickly
go
through
and
sort
of
push
and
pull
some
issues
in
and
out
of
the
milestone
to
accommodate
like
to
have
available
work.
D
While
we
were
waiting
for
other
things
to
happen,
it's
also
happened
where
we've
seen
like
like
high
priority
security
bugs
like
show
up
it'd,
be
like
or
regressions
like.
We
had
that
a
couple
milestones
ago
where
there
was
an
aggression
from
something
we
did
the
milestone
before
we,
and
it
was
like
severe
enough
that
we
wanted
to
fix
it
immediately
that
wasn't
planned
for
things
like
that.
They,
it
happens,
yeah,
so
the
most
part
we
try
to
do.
We
try
to
walk
off.
Of
that.
A
Taking
care
mostly
going
through
the
planning
issue,
so
with
that
in
mind,
because
this
this
makes
total
sense
by
the
way.
What
I
want
to
avoid
to
the
most
like
is.
Is
it
like
my
assumption
here?
Is
that
most
of
those
issues
that
then
come
in
apart
from
you
know,
like
a
high
severity
last
moments
like
regression
or
bug
those
things
have
already
been
weighted
and
kind
of
like
we
know
what
we
want
from
them
and
are
not
like?
A
Oh,
we
we
decide
to
bring
in
this
new
feature
instead
that
we
don't
like
it
hasn't,
been
groomed
or
anything
like
that.
That's
true
right,
I
think
so
gotcha
yeah,
and
that
brings
me
to
my
next
question.
This
is
the
thing
that
I
I
was
actually
having
a
discussion
this
morning
with
vitigod
from
ci.
About,
like
I
want
to
improve
developer
handoff
as
much
as
I
can.
A
So
when
I'm
done
with
an
issue,
I've
already
spoken
with
engineering
most
of
the
time
you
know
ask
them
like
hey.
Is
this
feasible
at
all?
What
do
you
think
of
this?
You
know
getting
some
feedback,
but
this
is
not
yet
like
the
the
discussion
you
have,
where
you're
going
to
bring
it
down
to
the
exact
mvc
scope
or
iteration,
towards
mvc
scope
that
we're
going
to
implement
for
first
milestone,
follow-up,
milestone,
etc.
Those
kind
of
things
those
discussions
need
their
own
separate
space
if
we
can
give
it
to
them.
A
So
my
first
question
would
be:
how
do
we
currently
on
in
general-
and
I
think,
nicole
might
be-
you
know-
might
have
the
clearest
overview
as
this
of
this
as
front-end
engineering
manager?
How
do
issues
move
from
product
designer
towards
engineers
and
that
they
feel
confident
in
what
they
need
to
build
like?
How
is
that?
How
is
that
process
currently
being
governed
by
labels
or
anything
else.
C
I'm
sorry,
the
planning
breakdown
label
generally,
that's
where
product
is,
is
flushing
out,
ideas
with
engineering
and
and
it
wouldn't
actually
get
into
like
the
scheduling
or
ready
for
development
phase
until
it's
gone
through
that
that
process.
That
being
said,
I
don't
know
how
heavily
or
re
uses
the
planning
breakdown
label
during
her
on
her
plan
board
or
during
her
plan
phase.
A
A
Okay
yeah,
so
so
my
my
thoughts
in
in
that
would
be
like
breakdown,
perfect
ideation.
I
would
not
like
to
see
that
within
the
planning
breakdown
session,
because
the
concept
should
already
be
clear
right
like
that's
where
and
I
think
like,
if
you,
if
you
ask
me
workflow
design-
is
not
specifically
product
design
relate.
It
can
also
be
for
engineers
to
figure
out
what
they
want
to
do
for
a
specific
technical
implementation
of
an
issue
or
something
like
that.
But
I
like
do.
A
C
So
for
for
clarification,
I,
I
would
say
not
ideation
rather
implementation
opportunities
or
challenges
is
probably
for
clarity.
I
I
don't
want
to
say
that
ideation
is
happening
happening
in
planning
breakdown,
because
I
think
generally
or
reit
tries
to
have
some
of
that
fleshed
out.
Etienne
might
be
able
to
speak
to
that,
though,
as
to
whether
or
not
that
happens
frequently.
B
B
B
Proposal
the
issue
proposal
has
been
worked.
People
worked
on
the
proposal
like
sufficiently
so
that
developers
can
add
a
way
to
the
issue.
To
me,
that's
the
planning
breakdown
when
we,
when
we
do
the
waiting
exercise,
maybe
waiting
is
something
that
you're
doing
dimitri
as
well
from
a
design
point
of
view.
B
A
A
Can
we
do
it
within
milestone?
Do
we
need
to
break
it
up?
What
does
this
mean?
When
are
we
gonna
make
it
user
facing?
How
are
we
gonna
approach
this
in
the
release,
management
or
the
the
release
post,
like
those
things,
are
kind
of
the
thing
where
at
least
I
from
my
side,
I'm
I
was
a
little
unclear,
so
this
is
cleared
up
a
lot
but
yeah.
A
I
would
I've
discussed
with
orit
to
kind
of
boil
it
down
to
one
thing,
because
we're
nearing
the
end
of
of
the
meeting
but
discuss
worry
like
hey?
Can
I
bring
issues
from
workflow
design
towards
workflow
planning
breakdown,
and
she
said
yes
for
sure,
like
you,
can
just
assign
the
label
and
work
and
go
from
there?
A
What
I
would
like
to
know
if
that
helps
like
does
that?
Does
that
move
an
issue
forward
at
all,
or
is
that
just
an
empty
label
assignment
and
there
needs
to
like
something
additional
needs
to
happen
in
order
to
make
sure
that
we
collaborate,
engineering
and
ux
that
that
issue
is
ready
for
implementation
fully,
as
as
much
as
it
can
be.
B
B
When
you
know
it's
when
the
issue
switches
to
workflow
planning
breakdown
and
then
at
this
point,
engineering
can
do
the
way.
Estimation,
if
there
is
more
if
there
is
more
like
feedback
that
needs
to
be
to
happen
and
to
be
received
by
to
be
received
by
by
by
ux,
then
maybe
the
issue
can
like
switch
back
to
workflow
design.
I'm
not.
B
A
Yeah
that
makes
sense.
I
I
totally
hear
what
you
say
too
many
too
many
actors
there.
I
think
it's
important
to
to
see
that
gitlab
is
currently
doing
it,
maybe
slightly
different
than
some
other
companies,
where
I
would
say,
planning
breakdown,
the
dri
in
normal
or
in
other
most
other
businesses
would
be
the
product
owner.
A
So
I
see
it
as
one
of
the
opportunities
where
I
think
hey,
I
see
issues
you
know
spilling
over
or
maybe
that
spillover
is
very
logical,
but
it
is
not
phrased
or
made
that
way,
because
the
planning
breakdown
happens
too
late
and
we
see
hey,
there's
additional
issues
that
need
to
create.
This
is
unfeasible
to
be
delivered
in
one
milestone.
A
While
we
thought
it
was
like,
like
those
kind
of
things
if
like
I
feel
like,
if
we
have
a
clearer
aligned
picture
on
hey,
this
is
when
the
feature
flag
will
be
introduced.
These
are
the
minimal
things
we
expect
and
to
be
developed
in.
However,
many
merge
quests
that
we
want
them
to
be
developed,
but
this
is
the
point
where
we
activate
the
feature
flag.
It
becomes
user
facing
we're
going
to
put
it
in
the
release
post.
A
It
might
make
a
little
bit
more
sense
and
open
up
that
conversation
for
both
engineering
and
either
pd
and
or
pm
decides
on
like
how
many,
how
much
time
we
can
involve
there
or
who's,
taking
up
the
the
stick
to
to
push
this
forward
and
and
allow
us
to
more
efficiently
kind
of
release.
The
features
that
we
do
and
make
sure
that
they
are
the
features
we
want
to
to
deploy.
As
as
we
thought,
they
should
be
right.
Yeah.
A
A
D
It's
all
manual
and
to
date
or
reit,
has
been
the
one
orchestrating
the
needs
weight
issue.
I
think
mostly,
I
think
other
people
have,
I
think,
nicole,
might
have
put
some
things
in
there.
You
know
for
angelo
and
some
other
other
things,
but
that's
the
process,
not
that
we
have
to
stick
to
that,
but
that's
just
how
it's
been
happening
thus
far.
A
B
C
A
This
this
helped
me
a
lot
I'll
what
my
action
point
for
this
and
then
I
want
to
make
sure
that
you
don't
have
any
action
points
or
don't
feel
obligated
to
I'll
bring
this
to
orit
and
discuss
how
I
can
more
effectively
bring
planning
breakdown
into
like
the
developer
handoff
process,
from
design
towards
the
build
track.
Right,
but
this
has
been
really
informational.