►
From YouTube: Verify & Release By weekly UX Meeting | 17 June 2020
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
So
welcome
everyone
to
verified
release.
You
acts
by
weekly
meeting
and
yeah
a
couple
of
read-only
items
mostly
about
the
upcoming
times
off,
so
go
through
that
yeah
and
jumping
into
the
discussion
items
area
we
have
out
like
your
stage.
Group
area
is
empty,
I'm,
not
sure
if
anyone
wants
to
share
anything
specific
happening
in
their
stage
group
add
to
the
agenda.
B
Right,
let
me
see
so
I
put
this
in
before
I
think
my
flights,
let
me
see
general
concept
of
an
issue
for
engineering
waiting
requested
by
p.m.
like.
How
do
you,
let
me
think
how
to
phrase
this
engineer
or
a
product
mentioned
ideally
once
like
all
of
the
issues
pre
waiting.
However,
you
know,
of
course,
it's
hard
to
wait,
something
if
it's
not
really
clear
what
you
know
the
eventual
concept
of
or
solution
will
be
and
there's
this
is
kind
of
like
a
balance
between
you
know.
B
Can
you
indicate
something,
because
that
is
what
waiting
ideally
is,
instead
of
like
actually
saying
what
what
exactly
goes
in
or
the
amount
of
effort
that
goes
in
first
is
like
now:
how
do
we
meet
in
the
middle?
That's
that's
what
I'm
trying
to
say
do
you
so
my
initial
question
would
be:
do
you
weigh
issues
in
your
stager
and,
if
so,
how
and
why.
C
C
What's
gonna
take
I
mean
we,
but
we
never
said
those
weights
I
think
it's
just
like
implicit,
that
we
know
that
these
design
is
gonna,
take
half
of
the
release
or
like
several
cycles,
so
their
release,
but
it's
never
communicated
and
I'm,
not
saying
that
that's
good
at
all.
It's
probably
a
failure
of
the
process.
I
teach
should
be
document
somewhere
and
I
definitely
want
to
do
that,
like
I
have
been
trying
to
communicate
expectations
of
bandwidth
and
like
the
amount
of
work,
but
I
have
one
group
so,
like
the
other
p.m.
C
can
see,
plan
against
that
I
have
been
trying
to
organize
that
a
little
bit
more,
but
yeah
I
just
wanted
to
be
honest
and
say
that
I'm
we're
not
waiting
anything
and
we're
not
really
we're
basically
eyeballing
those
efforts
and
kinda
like
having
that
in
the
back.
My
optimind,
you
know
like
again
I'm
not
saying
that
that's
good,
that's,
probably
very
bad,
but
that's
the
reality.
I
don't
want
it.
To
be
honest,
let.
B
Me
ask
a
slightly
like
a
slightly
different,
related
question.
In
that
sense,
okay,
you
ever
come
across
the
situation
where
engineering
wants
to
wait,
an
issue
where
just
like,
where
the
the
absolute
like
the
problem
statement,
is
not
such
a
good
place
that
you
know
you
can
say
for
certain
that
you
know
something
will
be
so
much
work
like,
for
example,
some
issues.
B
My
initial,
you
look
like
oh
we're,
gonna.
You
know
we're
going
to
tackle
this
issue
and
eventually
it
ends
up
being
an
epic,
because
it's
such
a
huge
thing
that
it
needs
to
be
broken
down
and
multiple
sub
issues,
and
only
one
of
those
sub
issues
will
be.
You
know
put
in
like
a
single
milestone
right.
C
That's
a
great
question:
I
think
that
happens,
but
not
that
often,
and
that's
probably
married
over
the
PM's
that
are
pretty
good
at
you
know.
P.M.
engineering
managers
I
think
they're,
pretty
good
in
mice.
I
think
that
has
happened
like
once
in
runner
that
we
were
thinking
about
this
particular
issue,
and
then
we
realize
that
okay,
there's
actually
many
things
underlying
things
and
we
need
to
break
down
into
multiple
issues
and
then
we
ended
up
with
like
44
any
issues,
but
that
didn't
impact
me
because
the
design
was
always
the
same.
C
C
It
only
changes
for
the
requirement
start
to
change
and
I.
Don't
know
that
until
someone
comes
and
say
like
hey,
we
cannot
do
that.
Or
can
we
explore
this
other
thing
or
whatever?
So
it's
very
it's
very
ad
hoc
I
will
say
you
know
it's
very
hard
to
do
it.
Just
when
we
decided
that
we
were
gonna
split
the
issue.
C
D
And
I
kind
of
thinking
out
loud
too
so
I.
The
way
that
we
do
waiting
here
is
really
odd
to
me,
especially
in
the
research
team.
We
don't
talk
about
the
weights
that
we
give
things.
We
have
no
shared
understanding
of
the
weights
that
we
give
things
in
you
you're,
never
supposed
to
use
a
weight
that
one
team
gives
something
to
give
that
week
to
another
team.
That
team
has
to
come
up
with
their
own
weight
for
it,
because
it's
it's
very
group,
contextual.
D
So
it's
very
weird:
that's
just
really
what
I
wanted
to
say:
okay
I'm,
especially
from
my
scrum
and
agile
training
that
I've
gone
through.
It's
just
odd.
The
way
that
we
do
it
and
it
doesn't
make
any
sense
because
we're
I
think
we
don't
even
have
user
stories
like
we
don't
break
it
down.
We
don't
talk
about
it.
It's
just
a
thing
like
one
says:
we
have
to
put
a
number
there
because
we're
gonna
hand
it
off
to
somebody
else,
but
that
number
is
not
gonna
mean
the
same
thing
to
them.
A
Yes,
it's
also
important
here
if
I
may
add,
my
20
cents
is
because
our
estimation
of
the
UX
work
is
a
little
bit
well
and
correct
me
if
you,
if
you
don't
agree,
but
it's
a
little
bit
different
from
the
estimation
of
the
engineering
work,
because
we
are
like
hey.
If
you
would
ask
ourselves,
why
do
we
as
a
product
designers
estimate
our
work?
A
The
only
one
reason,
probably
and
again
correct
me
if
I'm
wrong,
if
you
have
other
reasons
that
would
be
to
communicate
our
capacity
or
velocity
for
a
milestone
as
a
product
designer
to
product
management
or
to
the
team.
So
if
that's
the
reason
we
don't
even
like
I
would
I
would
ask
ourselves:
do
we
even
need
to
be
aligned
and
like
I
would
say
it
has?
The
estimation
should
be
done
clear
to
the
p.m.
on
the
product
designer
and
it
could
be
in
the
way
they
are.
You
know
comfortable
with
that.
A
Yeah
so-
and
you
know,
Jimmy
you
coming
back
to
your
question,
I
think
so
you
are
asking
like
what
I've
heard
from
you
is
the
fact
the
fact
like
when
we
have
those
situation
when
the
problem
is
not
100%
clear
and
then
we
are
going
into
a
little
bit
of
a
research,
try
to
understand
the
problem
better
and
then
we
understand.
Okay.
This
is
not
a
fly,
but
it's
a
whole
elephant
to
solve,
and
then
issue
grows
from
a
issue
to
an
epic
and
like
I
would
say
like
like
what
Huan
says.
A
It
almost
doesn't
happen
in
their
team.
I
really
happy
to
hear
that
my
answer
would
be.
It
should
almost
never
happen.
Well,
I
understand
that
will
be
Katie's
born
like
we
cannot
avoid
this
sometimes
like.
We
could
not
know
everything
but
yeah
like,
and
this
is
where
we
are
trying
to
like
work
around
the
process
right
now
and
like
I,
think
we
we
will
be
doing
better
there
soon,
because
I
feel
like
we're
doing
quite
some
work
with
a
tower
run,
alignment
and
the
processes.
A
So
that
should
not
happen
and
like
why-
and
here
also
posted
the
URL
for
the
UX
definition
of
done.
That
I
would
like
to
propose
starting
with
C
I
know.
It
actually
was
taken
by
inspiration
from
release
management
from
what
hey,
Anna
and
Jackie
have
started
working
from,
and
the
first
thing
it's
for
like
for
the
issue
that
is
about
to
move
to
the
design
workflow.
It's
the
problem
was
validated
and
understood,
so
it's
already
kind
of
like
yeah.
That
would
not
be
checked
for
the
case
that
we're
don't
be
here
about
yeah.
B
I
mean,
like
the
the
request
came
from
product
management,
like
Orion
said,
like
hey,
I,
wanna
I
want
us
to
be
in
a
state,
ideally
where
I
have
all
my
issues,
engineering
waiting
I
said
but
hey.
If
an
issue
is
engineering
waiter,
then
you
know
it
should
be
considered
to
some
extent
done
from
a
UX
perspective,
because
otherwise,
how
can
engineering
know
you
know
what
they
implement?
A
B
Then
she
says
like
she
stayed
like
yes,
I
I
understand,
but
you
know
we
should
be
like,
like
that's
coming
back
to
that
kind
of
eyeball
thing
and
like
it
was
an
unfinished,
it
was
an
unfinished
discussion
like
I
mainly
put
it
here
to
to
see
what
how
other
state
groups
did.
They're
waiting
or
not
I
mean
there
was
no
good
or
right
answer
here
or
good
a
bad
answer.
It
was
mostly
getting
a
little
bit
of
inspiration
and
also
to
ask
the
question:
like
hey:
does
your
p.m.
B
require
or
ask
of
you
to
for
engineering,
to
weigh
issues
that
are
like
not
in
any
way
having
that
definition
of
done
to
some
extent
right
like,
and
this
is
this
comes
down
as
well
like
hey?
If
we
have
it
and
like
if
we
have
an
engineering
team,
an
engineering
team
that
consists
out
of
like,
for
example,
for
for
engineers
or
five
engineers
and
there's
only
one
product
designer
to
pick
them
up?
And
in
order
to
for
engineering
to
weigh
those
issues,
then
they
need
to
be
in
some
extent
of
you.
B
D
Yes
and
I
was
wondering:
do
we
ever
have
a
conversation
with
engineering
where
the
whole
purpose
is
for
designed
to
communicate
to
engineering?
What
has
been
designed?
Why
and
engineering
to
weight
in
on?
Oh,
that's,
gonna
need
this
and
I'm
gonna
need
to
go
research
that
and
okay
I
think
this
might
be
done
this
way,
and
then,
in
that
conversation
let
engineering
actually
wait
what
they
understand
about
that
design
issue
in
terms
of
their
effort
right
there.
D
B
B
C
It's
not
a
consistent
thing
in
in
the
sense
that
it's
not
something
that
we
have
every
time
that
there's
designs
we
meet,
then
we
discuss
them
like.
Usually
it's
very.
It
seems
that
we
need
to
talk
about
these
and
then
we
get
together
and
talk
about
it.
You
know,
but
it's
very
random,
it's
not
it's
not
a
process.
It's
not
something
like
that.
It's
usually
just
when
the
assign
is
ready
and
there's
gaps
in
the
understanding.
Then
we
get
together
and
then
we
talk
about
it
and
then
but
yeah.
C
A
E
If
I
think
you
my
two
cents
on
that,
it
doesn't
work
pretty
well
because
yeah
too
many
variables
in
for
the
engineers
is
wait.
One.
It's
one
word
request
way
to
use
too
much
of
less
whatever
and
I'm
sure
this
wasn't
I
discussed,
but
to
me
what
works
and
what
helps
is
to
make
it
visible,
which
design
tasks
I
need
to
complete.
E
In
order
to
close
that,
we
should
like
to
move
from
the
UX
workflow
and
that's
how
I
wait
if
that's
gonna
take
a
week
two
months
or
two
days
that
mean
it
depends
on
yeah
how
small
the
issue
is
or
how
I'm
cooperating
with
the
team
he's,
pissed,
infamously,
asynchronously,
etc.
So
I
not
have
to
make
for
the
conversation.
But
those
are
my
image
of
distance
I.
B
Think,
thanks
for
that,
Diana
I
looked
at
your
like
the
original
issue
that
I
think
put
in
here
in
at
21,
and
do
you
still
like
one
question
one?
They
still
work
with
that
definition
of
done
list
alright
and
to
like,
if
I
look
at
that
that,
like
definition
of
done,
even
though
we
like
it
is
like
you
become
more
like
it,
make
it
more
visible,
this
is
what
I
really
like
about
it.
But
if
I
look
at,
for
example,
criteria
for
UX
done,
it
says
no,
all
right.
B
You
explain
well
at
it
user
stories
as
case
we
confirmed
and
then
liked
it
pretty
quickly
goes
towards
a
state
where,
apparently,
suddenly
you
have
a
solution
like
there's
a
lot
of
work
between,
like
you
know,
defining
that
solution
like
there's
there's
some
times
you
might.
You
know
like
have
one
to
two
iterations
of
a
little
model
and
then
you're
done
at
that
solution.
B
You're
you
get
at
the
ideal
solution
because
it
was
Qaddafi
is,
and
you
just
you
know,
figure
it
out
some
some
minor
details
and
then
there's
other
places
where
you
know
before
you
get
to
that
stage.
You
went
through
thirteen
fourteen
iterations.
You
have
to
ask
if
to
look
back
like
it.
That
is
not
really
visible
in
like
a
single
task
in
a
list
like
that,
little
tasks
can
be
huge
or
can
be
like
a
little
mouse
right.
Yeah.
E
That's
why
for
these
cases,
where
so
principal
something
that
we
consider
you
acts
ready
where
I
created
user
stories
and
prototypes
whatever
once
it
goes
to
playing
break
down
for
some
reason,
there's
a
change
in
scope,
right,
there's
a
change
technology
or
whatever.
Then
it
goes
back
to
the
design
workflow
and
then
that
task
sets.
E
You
know,
I
just
checked,
as
you
I,
don't
know:
Martha's,
ready
for
engineer,
evaluation,
evaluation
or
has
user
stories
I'm
just
going
work
on
those
pieces
that
are
missing
in
the
story
and
for
us
at
least
that's
what
works
for
release
management
and
that's
also
what's
reflected
here-
is
that
because
we
are
constantly
iterating
on
something
on
the
issues,
sometimes
I'm,
not
even
working
by
us
definition
of
them.
Jackie's
already
validating
the
problem
here
and
talking
to
customers
and
I'm
already
doing
some
low
fidelity,
prototyping
and
then
engineers
are
on
the
side
working
on
validating.
E
Like
some
things
on
the
API,
then
at
some
point
we
know
that
we
have
like
the
pieces
of
the
story
and
then
yeah.
We
look
back
at
that.
Then
you
ask
yo
D
and
say:
okay,
we
have
initial
user
stories.
You
have
the
criteria,
let's
work
on
that,
so
for
us
it's
granular
to
a
certain
extent.
That's
what
you
see
in
this
DoD,
because
we
don't
follow
like
this
clear.
That's
right
it
does
designer.
Is
that
at
least
my
experiencing
I
get
lab.
Is
that
it's
very
difficult
to
just
start
here
and
there
as.
E
B
B
However,
that
keeps
being
a
theme
in
other
states
troops
where
hey.
We
know
this
only
being
now
and
we
need
to
work
on
implementation
issues
that
are
like
the
clock
is
ticking.
You
know
we
don't
have
that
that
leisure
and
it
seems
very
hard
to
get
out
of
that
that
place,
because
that
seems
to
be
the
recurring
theme
every
time
this
these
things
come
out.
Hey.
You
only
have
this
amount
of
time
to
work
on
this.
We
will
be
stuck
at
some
point
and
we
will
have
to
make
concessions
yeah.
E
E
So
you
know,
but
I
suggest
a
wrap-up
I
think
that's
what
works
for
us.
That's
what
I've
seen
really
reflected
on
how
we
applied
a
max
Tod
and
how
I
work
on
these
items
is
that
I
know
that,
for
example,
Jack
he's
gonna
follow
up
with
an
item
that
it's
in
the
direction
and
the
vision
page
for
Razer
frustration.
E
There
are
no
surprises
there
unless
there
is
a
big
change,
you
know
in
the
market
or
with
our
customers,
but
we
validate
our
problems
so
much
that
we
know
that
we
are
working
on
secret
management
and
that
we
have
to
work
on
this
this
and
that
and
that's
where
the
the
backlog
comes
from.
So
it's
I,
don't
think
it's
I.
You
actually
unease
when
I
solve
that
problem.
You
know.
A
A
This
way
so
to
me,
it
seems
like
some
like
it
really
depends
on
the
product
manager
right
and
some
people
are
really
like
to
work
like
really
ahead
right
and
like
this,
what
I'm
curious
like
I'm,
maturing
Dimity
you
one
only,
for
example,
will
even
ever
be
working
on
15.6
I
do
not
know
so,
maybe
we
have
to
like.
We
have
to
be
experimenting
until
we
will
find.
A
Yeah
come
up
with
our
own,
like
definition
of
down
or
like
all
those
techniques
and
orthotics.
That
would
help
us
to
get
just
enough
to
move
forward
and,
of
course,
try
to
cut
a
little
bit
ahead
but
see
how
that
will
go
and
what
I
also
have
seen
from
Vienna
from
you,
or
some
of
your,
for
example,
issues
that
we
don't
necessarily
need
to
have
the
full
ready
you
acts
and
work,
mock-ups
descriptions,
I
know
whatever
we
deliver.
You
acts
in
in
order
for
engineering.
A
To
give
an
estimation
of
the
wedding
you
can
like
I
think
what
I've
seen
you
can
often
do
you
kind
of
like
just
describe
whatever
it's
like
this
feature,
gonna
resolved
into
at
this
point
of
time,
and
then
it
gives
them
well
enough
information
to
do
an
estimate.
We
don't
have
to
be
super
clear
about
those
estimations
at
that
point
of
time,
I
think
from
the
engineering
as
well.
It's
just
like
kind
of
proximate
understanding,
because.
E
With
us
we're
constantly
discussing
things
in
the
and
channels
right,
so
you
have
a
think
big
session.
You
have
select.
You
have
the
issue
comments
whatever
and
when
I
push
when
I
post
a
design
proposal,
it's
not
gonna,
be
this
source
of
truth
right,
they're
still,
gonna,
look
at
it
and
then
discuss.
If
can
we
break
this
down
into
something
smaller?
Can
we
not
use
a
for
Gemma
component?
E
Can
we
do
this
this
and
that
and
then
after
I
think
that's
what
we
all
do
you
update
the
description,
but
sometimes
most
of
most
of
the
times,
because
I'm
not
also
creating
big
changes
to
the
UI
I?
Have
it's
a
luxury
as
well
to
say
just
I,
don't
need
to.
You
know,
work
on
prototypes
because
I
can
describe
to
them.
E
What's
going
to
change
and
they're
just
gonna
work
on
top
of
that,
but
I
try
to
go
back
the
bare
minimum
in
the
issue
as
in
delivery
assets,
because
I
know
that
these
are
going
to
change.
I
know
that
another
team
is
working
on
whatever
component
or
the
data
migration.
Whatever
and
I,
don't
want
to
work
on
prototypes.
So
I,
don't
only
if
it's
really
really
necessary,
but
also
my
team
they're,
very
design
minded
so
I
know
that
nathan
is
going
to
prototype
something
for
me
so
that
I
can
validate.
E
A
A
If
we
feel
like,
we
need
more
discussions
on
this,
let's
open
up
an
issue
and
have
maybe
involvement
across
stage
people,
because
Demetri
I
know
that
Maria
in
in
ops,
a
lot
of
designers
are
doing
weights,
putting
weights
on
the
issues,
I'm,
not
sure
how
they're
waiting
compress
the
engineering
workflow
but
yeah.
Maybe
that's
also
an
interesting
path
for
us
to
investigate.
A
A
Okay,
then,
now
I'm
moving
on
to
my
item,
which
is
the
next,
so
it's
actually
somehow
related
and
I.
Don't
want
to
get
it
too
much
time
right
now
for
discussion,
because
there
is
a
lot
of
things
to
read
and
basically
I
would
like
to
get
your
feedback
on
this
issue
that
I've
created
summarizing
some
of
the
challenges
that
I
observed
from
some
of
the
stage
groups,
it's
very
related
to
what
Dimitri
just
now
said,
and
maybe
some
additional
points
on
that
required
some
text.
B
Things
in
terms
of
recording
planning,
kickoff
videos,
I,
was
wondering
when
your
p.m.
say
it
says
you
can
record
it
like.
When
did
you
record?
Did
you
record
it
on
the
16th,
or
did
you
record
it
like
a
way
week
for
or
even
two
weeks?
If
so,
why
and
how
does
it
relate
to
any
spill
over
from,
like
last
milestone,
I
have
had
the
comments
from
from
p.m.
like
hey.
B
We
cannot
do
this,
this
recording
unless
we
know
they
spill
open
spill,
overs
Oh
me
alone
until
the
last
second,
so
this
kind
of,
like
in
terms
of
like
recording
this
kickoff
video
together
with
p.m.
this,
leaves
only
a
very
small
window
to
do
so.
If
somebody's
out
of
office
hello,
then
it
makes
it
very
hard
to
record
that
video,
so
I
was
wondering
how
others
tackle
that
or
are
you
know
what
their
process
is.
E
We're
gonna
watch
my
comment
here:
that's
we
recorded
at
the
end
of
the
current
milestone,
but
yeah
the
planning
was
already
there.
So
like
what
I
said
before
me,
we
already
knew
what's
going
to
to
be
delivered
and
like
when
you
mention
like
this
fuel
arrest,
then
we
didn't
even
mention
those
the
things
that
teen
are
gonna,
but
things
are
carried
over
from
13.1
to
13.2.
E
We
didn't
even
mention
those
it's
really
like
new
items
and
new
acts,
items
that,
like
for
engineering
and
UX
items,
that
kind
of
follow
the
product
vision
that
meet
the
direction
and
we
did
record
together,
jackie
and
I,
but
there
was
also
a
proposal
there
to
do
it
separately.
So
I'll
just
record
my
part
in
but
yeah
we
ended
up
doing
it
together.
I
think
that
could
also
work
if
we
don't
like
our
office
or
the
UX
plane
is
ready,
but
the
other
part
is
not
yeah.
B
It
was
like
a
small
comment
and
before
we
go
to
Kwan's
point,
I
didn't
like
to
thank
thanks
for
that.
I
understand
the
point
of
like
not
mentioning
the
the
spillover.
It's
not
about
mentioning
the
spillover,
it's
more
about
that
spillover
will
take
up
capacity
of
any
new
items
going
into
current
master,
yes
or
no,
so,
depending
on
that
spillover.
If
it's
a
lot,
then
hey
those
new
issues
we
wanted
to
talk
about
will
actually
not
be
delivered
in
current
milestone.
Thus
we
cannot
talk
about
it
that
is
kind
of
like
the
problem.
C
Yeah
I
mean
it
did
happen
and
these
one
for
me.
We
actually
had
spillover,
but
we
deep
I
mean
at
least
what
I
did
was
just
like
talking
about
spillover
as
it's
not
a
spillover.
You
know
what
I'm
saying
sideboards
we're
just
gonna
be
working
on
these,
so
I
mean
it's
kind
of
weird,
but
it
can
happen
that
in
two
consecutive
releases
you
are
talking
about
the
same
thing
and
I
think
that
well,
that's
fine
I,
don't
know
Nadia,
maybe
has
talked
to
that.
C
But
what
I'm
saying
is
like,
let's
say
like
this
release,
you
say
you
X
is
gonna,
be
working
on
creating
group
coverage
graphs
on
blah
blah
blah.
It's
gonna
be
doing
this
issue
on
this
issue,
and
then
you
work
on
that
a
little
bit
and
you
do
a
lot
of
stuff.
You
do
research
and
like,
but
like
nothing
gets
quite
done
because
there's
competing
priorities
or
whatever
and
then
in
the
next
one.
It
happens
that
you
need
to
push
that
same
issue
to
the
next
one.
C
B
A
I
just
want
to
clarify
to
me:
I
understand
this
correctly,
so
you
are
saying,
for
example,
that
we
cannot
record
the
video
until
almost
to
the
stage
to
understand
what
things
are.
Gonna
miss
the
milestone
and
move
on
from
this
milestone
to
the
next
one.
Oh.
B
This
this
happens
every
milestone,
because,
like
engineering
will
not
be
able
to
complete
all
the
things
that
went
into
that
milestone,
does
it
will
take
up
additional
time
in
the
next
milestone
which,
like
this,
this
kind
of
like
this?
Is
the
thing
that
like?
If
we
wouldn't
account
for
that,
then
we
could
record
that
meeting
way
in
advance,
like
no
probably.
C
It
also
happens
automatically
right
once
it's
past
certain
date.
It
gets
that
tag
that
label.
That
says
me
thirteen
point
one
or
thirteen
point
two
or
whatever,
so
you
don't
even
need
to
be
like
fully
aware
of.
What's
going
on
like
like
there's,
there's
I,
don't
know,
what's
the
deadline
log
like
that,
basically,
what's
the
I.
B
A
So
our
product
development
workflow
says
that
we
should
have
all
the
items
that
are
going
into
the
release.
What
is
that
we
ready
before
that?
But
it
sounds
like
you're
having
it
a
week
after
pretty
much
I
mean,
like
I,
think
my
opinion
and
I
may
be
wrong
here.
Maybe
I'm
missing
some
data,
but
I
think
we
should
don't
be
having
a
dependency
here,
because
those
things
should
be
known.
A
bit
more
upfront.
I
know
this
is
a
little
bit
weird.
A
E
Yes,
so
we
have
all
the
time
that
yeah
something's
on
the
labor
because
and
then
it
carries
over
to
the
next
milestone,
but
he
wax
is
ready.
So
what
happens
that
Jackie
mentions
yeah
we're
gonna,
continue
working
on
making
possible
to
add
releases
to
the
UI
and
then
that's
it.
We're
delivering
the
item,
but
you
axe
is
ready
so
that
doesn't
affect
my
capacity.
It
might
affect
the
capacity
of
developers
being
able
to
work
on
new
items,
but
because
they
already
have
they
are
assigned
to
items
that
I'm
grooming
or
that
we
are
validating.
B
I
think
I
think
it's
I
think
it's
important
to
like
I
think
we're
slightly
misaligned
in
terms
of
like
what
we're
like
the
idea
here
is
like.
When
can
we
record
the
kickoff
video
and
does
or
does
not
spill
over
from
last
milestone
effect?
What
we
will
put
into
that
kickoff
meeting
and
I
mean
the
kickoff
meeting,
4
p.m.
will
mean
what
engineering
is
working
on
and
then
because
it's
a
collaboration,
it
will
now
also
include
what
UX
will
be
working
on.
I
totally
understand
that
for
UX
it
has
no
effect
right
spill
over.
B
We
don't
care.
We
work
on
the
next
thing,
however
engineering
it
does.
So
what?
When
PM
wants
to
record
and
say,
what's
in
the
next
milestone,
what
engineering
will
be
implement?
That
is
like
what
what
I?
What
I
get
is
that
release
management
doesn't
have
no
effect
for
that,
like
Ken
Ken
for
release
management,
Ken
Jackie
record
a
video
like
two
weeks
in
events,
no
problem
and
spillover
will
not
affect
what
engineering
we'll
be
working
on
next
milestone
or.
B
E
We
already
know
we
already
know,
what's
going
to
get
filled
over
right,
so,
for
example,
I
just
lived
here
in
the
plenty
issues
for
13.2
that
was
open
three
months
three
weeks
ago
and
also
the
needs
weight
issue,
so
everything
it's
very
clear
to
what
issues
that
we
need
engineers
to
be
grooming.
What
issues
are
gonna
miss
milestone,
what
it
so
it
affects,
but
we
know
ahead
of
time.
So
that's
why?
For
us
there
is
this
confidence
to
record
a
video
two
weeks
ahead.
B
E
I'm
not
sure
about
two
weeks,
but
there
is
a
we
track.
Everything
week
we
and
also
I
think
I
implement
a
new
process
to
make
daily
or
weekly
updates
on
the
issue,
as
likely
be
informing,
saying
like
this
is
the
status
of
this
issue
or
this
merging
past
by
the
end
of
this
week
or
by
the
end
of
the
day.
So
we
keep
like
a
lot
of
tracking
the
yeah
cuz.
B
A
C
But
I
I
don't
think
that
happens
like
at
least
in
testing
now
that
I'm
thinking
about
it
like
every
week
when
we
meet
we
say.
Are
we
confident
that
this
is
gonna
ship
in
this
release?
And
then
they
say
like
yes
or
no
or
maybe
you're
like
maybe
this
far
or
maybe
we
need
to
break
this
far
whatever
like
there's
the
discussion,
happiness
right
but
I
think
we're
pretty
aware
of.
What's
gonna
make
it
to
the
release
and
whatnot
we're.
A
A
On,
like
the
the
estimation,
the
planning-
and
maybe
we
have
to
discuss
this
with
a
read
and
maybe
involve
some
of
the
other
product
managers
to
line
up
for
some
best
practices
or
tips
because
it
again
comes
back
to
the
question
of
planning
and
I'll
definitely
know
this
for
myself.
So
we'll
look
into
this
deeper
as
well.
I'll.
B
E
E
Or
how
can
they
make
visible
for
themselves
without
having
to
ask
all
the
time
the
developers,
because
I
remember
working
in
progressive
deliveries
that
that
was
a
very
big
problem
as
he,
the
PM
doesn't
have
an
overview
of
what's
happening
and
what
can
be
delivered
and
what
you
know?
It's
it's
a
it's
missing
the
milestone.
So
if
you
have
it
in
one
place,
then
you
know,
and
then
you
can
check
with
it
rather
than
waiting
for
them
to
yeah.
They
can
give
you
the
feedback.
I.
A
B
I
got
a
lot
of
items.
Sorry
liar.
Let
me
see,
let's
see
if
we
can
quickly
go
through
so
notice,
to
see
as
monthly
engineering
we
need
to
go.
We
take
that
how
how
about
we
doing
is
cross-functionally
for
UX.
That
I
thought
might
be
interesting.
Just
an
idea
just
wondering
what
thoughts
are
not
intending
to
speak
in
half
and
a
half
an
hour
about
this.
B
C
A
C
I
mean
I
definitely
see
a
lot
of
value
in
these,
because
otherwise
it's
kind
of
hard
to
understand
where
I
mean
they
take
that
one.
The
way
at
that
I
understand
it
is
that
it
Greek
brings
attention
to
the
engineering
team
about
what's
what's
important,
start
fixing
when
it
comes
to
tech
that
you
know
it
just
basically
allows
them
to
shift
attention
to
things
are
creating
other
issues,
so
I
think
I
see
it
the
same
way
right
like
it's.
C
If
we
can
get
together
and
discuss
them
and
see
how
we
can
like,
if
fixing
those
issues
is
gonna
help
us
unblock
other
issues
or
so
like
major
cross-functional
cross
team
problems.
I
definitely
see
the
merit
in
doing
it.
Yeah
I
just
was
wondering
if
we
could
do
it
as
synchronous
or
asynchronous
Li,
but
I
think
the
values
there
I
would
definitely
love
to
have
something
to
discuss.
Ii
synchronously
that
works
I'm.
Just
saying
that
I
think
it's
helpful
in
in
either
format.
E
E
So,
for
example,
we
have
we're
gonna
work
on
secrets
and
spilling
secrets
from
sea-ice
variables,
so
there's
a
bunch
of
issues
and
new
acts
that
bugs
or
whatever
that
they
touch
the
settings
page
right.
So
that's
the
point.
You're
gonna
have
to
address
that.
So
it
will
be
interesting
to
have
a
conversation
about
this
specific
topic
but
yeah.
It
really
depends
I,
see.
B
I
see
your
question
as
well:
Miriam,
do
you
think
having
such
an
issue
for
each
stage?
Yes
or
no?
What
I've
always
found
hard
to
understand,
which
has
also
been
why
I've
been
working
with
the
needs?
Ux
review,
epoch
differently
than
I
think
that
Nadia
has
because
Nadia
in
the
meets
UX
review,
epoch
I
know
this
going
on
tangent,
but
just
for
a
small
bit,
you
are
adding
the
issues
towards
that
ethic
right
like
as,
if,
like
as
a
child
issued
towards
that
epoch,.
E
B
Because,
like
the
thing
I'm
getting
at
is
like
what
is
the
use
of
epics
versus
labels
right
like
if
we
need
a
bucket,
we
already
have
one
in
like,
for
example,
we
are
like
in
PD
and
see
I
have
been
trying
really
hard
to
get.
You
know
everything
try
aged,
and
in
that
way
you
know
you
can
more
easily
get
them
scheduled
in,
because
you
can
see
like
hey
out
of
all
our
issues.
B
While
for
an
epic,
you
know
an
epic
is
more
like
as
I
see
it
like
I
understand,
you
can
use
it
as
a
bucket,
but
it
like
an
epic
should
have
a
meaning
towards
like
it's
a
it's,
a
varieties
set
to
a
certain
like
it
needs
to
solve
some
something
in
a
limited
time
span.
Whatever
that
time
span
is
right,.
E
Yes,
if
you
assign
the
dates
and
the
master,
but
they
to
be
a
trade.
So
for
us
it's
really
when
I
say
I
collect
all
the
bugs
in
this
bucket.
It's
because
we
are
scheduling.
One
knew
except
for
milestone,
so
at
some
point
or
go,
is
to
kill
close
that
epic
right,
but,
for
example,
I
linked
here
this
one,
this
bucket,
which
is
bugs
to
fix
that,
includes
you
except
you
wanna,
polish
and
general
bugs
that
includes
new
axe
to
the
environments.
E
The
goal
is
to
close
those
first
and
then
move
to
environment,
new
features
so
using
labels.
Yes,
we
could
use
labels
there,
but
it
doesn't
really
gives
us
the
visualization
that
we
wants
to
just
say:
these
are
the
items
collecting
here:
they're,
probably
labeled,
all
the
same,
but
it's
really
just
for
visualization
that
yeah
yeah.
B
E
B
A
D
D
And
that's
why
I
wrote
there
in
my
comment:
not
knowing
all
that
but
I
suspected
that,
typically,
if
it's
something
longitudinal
like
step,
one
builds
on
step.
Two
builds
on
step.
Three
you'll
want
to
put
together
like
a
research
plan
and
that's
different
from
a
project,
because
the
plan
is
overarching
all
of
the
things
that
you
think
you
might
need
to
do
in
order
to
be
successful.
The
project's
live
inside
that
plan,
so
each
individual
research
efforts
are
part
of
that
plan,
but
they're
not
the
only
thing
going
on.
D
A
C
Yeah,
so
we
never
use
that,
but
I
think
that
we
will
use
it
more
because
it's
interesting.
So
it's
just
a
rate
item,
so
I
saw
this
particle
for
someone
is
like
criticizing
how
github
is
changing
things
and
like
it's
very
interesting,
because
the
way
that
he
perceives
github,
you
know
github
seems
mostly
for
people
like,
like
a
social
network
like
a
social
layer
of
code
and
discovery
of
solutions
or
what
not,
and
they
of
course
use
it.
A
subversion
control
as
well,
but
I,
don't
know.
I.
C
Just
kind
of
thought
like
like
the
food
for
thought
here
is
like
if
you're
gonna
read
that
you
realize
that
github
feels
a
lot
like
the
consumer
type
of
solution
of
the
space,
and
we
feel
more
like
surprised,
like
the
professional
productivity
tool
and
I,
was
wondering
how
we
can
leverage
that
to
make
us
a
stronger
and
everything
that
we
do.
You
know.