►
From YouTube: Work items weekly sync - 2021-10-26
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
B
C
C
B
And
journey,
what
do
you
mean
by
journey
donald?
Do
you
mean
like
literally
like
how
do
I
get
from
step
a
to
b,
or
do
you
mean
journey
as
in
like
here's,
this
large
journey?
Oh,
they
need
to
create
a
thing.
They
need
to
create
a
work
item
and
then
they
need
to
edit
a
work
item
or
is
it
like,
while
the
user
is
creating
the
work
item,
they
need
to
do
this
this
this
this
to
create
it,
which
is
it
the
first
of
the
sector.
F
I
think
it's
a
bit
of
both
actually
like
a
bit
of
the
high
level
and
a
bit
of
the
details
because,
like
we
do
have
the
new
issue,
does
that
button
stay
in
place
or
does
it
get
replaced
with
the
new
work
item?
So
that's
that's
a
detailed
thing
right
because
we
know
how
we
get
to
the
issues
list,
but
then
what
does
the
button
say
next
then?
F
F
Then
what
gets
displayed
on
the
list
itself
do
this
like?
Do
we
display
only
that
type
of
the
item
that
was
just
created
or
everything
and
that
pops
up
at
the
top?
So
I
I
think,
like
this
kind
of
smaller
details,
I
guess
but
then,
like
the
biggest
question
for
me,
is
like:
where
do
we?
Where
does
the
user
find
this
new
work
item
button?
Is
it
like
a
totally
separate
list?
Is
it
on
the
issues
list
from
the
issues
menu.
B
F
Not
probably
not
into
all
the
eh
cases,
I
would
be
interested
in
one
simple
flow
like
here's
where
it
starts
here
are
the
steps
that
user
needs
to
take
and
then
here's
where
they
land
or
this,
where
they
see
the
result
kind
of
thing
so
like
it
can
be
in
high
la
like
in
big
lines,
but
also
like
describing
the
journey
in
a
more
specific
way.
If
that
makes
sense,.
A
To
me,
that's
a
user
flow
and
I
think
one
of
the
reasons
correct
me
if
I'm
wrong
alexis,
but
I
think
one
of
the
reasons
that
alexis
was
looking
for
confirmation
is
because
or
clarification
is
because,
when
ux
thinks
of
a
journey,
I
think
we
tend
to
think
of
a
journey
map
which
is
something
where
you
document
at
a
high
level.
The
user's
experience
kind
of
through
a
specific
flow
and
you're
outlining
like
the
emotional
aspects
of
the
journey
and
key
touch
points
and
things
like
that.
A
But
it's
not
it's
not
super
focused
on
the
granular
details
of
the
how
it's
more
like
the
the
what
they're
trying
to
accomplish,
and
so
I
think
a
user
flow
is
what
we're
actually
looking
for,
which
I
had
started
a
simple
mural
on
that
and
I
posted
it
down
here.
But
it's
very
basic
right
now,
but
it
could
be
something
we
could
build
on
if
it
would
be
helpful.
B
C
C
C
C
Yeah,
but
that
I
think,
might
help
us
because
if
then
we'd
be
navigating
to
the
list
page
to
the
new
form,
it
would
get
us
around
a
lot
of
these,
and
then
we
could
have
the
other
questions
like
what
alex
was
saying
like
when
you're
on
that
list
page.
What
gets
populated
in
the
template
from
the
the
actual
work
types
metadata
like
it's
titled.
Does
that
get
into
each
ad
button
and
the
title
of
the
page
and
like
all
the
questions
we
have
to
figure
out.
B
And
I
mean
how
okay
that
leads
into
my
next
point,
because
then
you
already
did
a
great
job
kind
of
mapping
out
some
of
this
flow
of
the
flow.
I
guess
kind
of
the
journey,
if
I'm
using
the
language
that
you
all
are
using
of
the
user
here
and
mapping
out
the
stories
in
the
spreadsheet.
So
do
you
think
we
need
to
just
expand
on
that?
Or
do
you
all
want
to
start
over
not
being
in
another
way?
Do
we
need
to
keep
mapping?
B
C
G
Yeah,
I
get
all
that
I
think
for
me
well
and
I,
if
I'm
confused,
I'm
sure
it
also.
It's
also,
maybe
where
some
others
are
confused.
It's
just
like
the
the
user
flow
is
in
like
where
it's
clear
what
a
work
item
detail
is
going
to
be
and
what
can
do
and
what
parenting
is
going
to
be
on
that.
Like
that's
all,
I
think,
that's
pretty
straightforward,
but
it's
like
we
have
this
track.
G
What
does
that
look
like,
I
guess,
and
how
do
we
iteratively
work
towards
that
right
without
because,
right
now
it
sounds
like
we're
talking
about
like
building
a
whole
new
list
experience
and
like
a
whole,
like
all
these
things
like
out
of
the
gate
which,
if
that's
what
we
need
to
do,
we
can.
But
there's
also
is
there
a
way
to
iterate
in
smaller
pieces
to
get
to
the
end
state
while
shipping
customer
value,
I
guess,
is
the
question.
C
I
think
you're
right
on
and
like
we're
getting
into
details
and
finer
points
which
I
think
should
be
more
like
vision
and
then
we
could
iterate
and
shift
something.
That's
way
more
simple
in
the
meantime,
just
to
prove
the
concept
and
then
make
it
better
as
we
go
so
potentially
that
rollout
menu
wouldn't
make
sense,
but
we
could
just
hard
code
for
now
just
the
items
in
it
and
hard
code.
Everything
essentially
just
to
get
the
mvc
up,
wants
to
see
the
big
picture.
So
they
kind
of
know.
What's
coming.
G
Yeah
one
less
view,
and
maybe
you
can
and
that's
where,
like
what
I
was
working
towards
before
we
start
on
this
with
the
issue
type.
Is
you
basically
have
one
list
view
for
issues
or
which
will
be
future
work
items
you
can
filter
by
type?
And
then,
when
you
work
when
chris
and
when
you
build
out
the
safe
queries
and
filtering,
then
like
people
can
build
out
their
own
list
experience
with
whatever
types
they
want.
It
right.
C
C
I
Yeah,
I
think
that's
right.
I
think
we
apologies
to
the
eox
folks
for,
like
I'm
sure,
using
the
wrong
language
several
times
over
the
course
of
this
like
ask,
because
it's
just
like
you're,
you
have
very
specific
definitions.
Thank
you
by
the
way
blair
for
providing
some
of
those
links.
So
I
can
read
up
on
what
all
these
things
actually
are,
but
what
gabe
said
of
like
we
have
point
a
now
right.
We
have
issues
and
we
are
kind
of
from
an
engineering
perspective,
we're
iteratively,
shaping
issues
to
be
work
items.
I
So
how
and
then
eventually,
like
you
know
and
end
state,
we
have
a
really
nice
work
items
list,
that's
filterable,
but
as
we
get
into
this
mvc
where
we
have
to
actually
start
flipping
some
of
the
switches
so
that
issues
our
work
items.
What
what
do
things
look
like
like?
What
is
the
you
know?
Do
we
keep
using
the
existing
issue
list
and
we
need
to
add
filter
sport
or
or
do
we
have
a
new
list?
I
C
That
makes
sense-
and
I
would
say
too
just
for
hearing
that,
like
we're
not
going
to
redesign
the
issue
lists
right
now,
I
don't
think
we
should
spend.
I
think
we
should
spend
all
of
our
energy
on
the
new
modal
or
the
new
list
view
or
sorry,
the
detail,
view
of
work
items
and
use
what
we
have
but
make
them
work
like
filtering.
If
we
have
to
this
was
another
spreadsheet.
I
know
we
started
at
the
very
start,
but
the
it's
kind
of
where
we
are
now.
C
C
Eventually
we
needed
to
add
this
new
one
for
adding
new
objects
as
well
as
this
is
what
we're
talking
about
now,
but
like
a
combined
list
view
that
can
handle
the
new
object
so
that
discussion
of
what
needs
to
be
on
that
combined
list
view
or
the
one
that
can
work
for
all
of
our
new
work
item
objects.
That's
I
guess
what
we're
getting
into
right
now.
C
G
This.
The
user
flows
there,
even
if
we
don't
work
on
it
right
now,
but
just
thinking
through
it
and
like
sort
of
I
don't
know
if
you've
seen
the
incremental
and
inner
motor
lisa
idea,
where
you
kind
of
take
both
iterative
and
incremental
approach
to
like
painting
the
picture
right,
you
know
sketch
it
all
out,
and
then
you
start
filling
in
with
different
colors
different
thoughts.
D
G
That
make
sense
yeah.
I
think
I
think
it's
possible
because
we
can
build
iteratively
and
incrementally
and
just
depending
on
when
we
want
to
expose
things
to
the
end
users
right,
and
I
think
that's
the
the
sort
of
like
trying
to
decouple
this
a
little
bit
of
like
we'll
ship
it
to
customers
when,
as
soon
as
we
can
as
soon
as
there's
something
that
is
valuable,
that
we
can
ship.
G
F
That's
so
that's
what
my
confusion
is
as
well
is
like
how
do
these
two
coexist,
the
existing
issues
and
epics,
and
all
that
stuff
like
right?
We
have
create
quick,
usually,
and
then
we
are
adding
the
the
feature
which
is
feels
like
it's
something
greenfield
that
we
want
to
kind
of
build
from
scratch,
and
now
I
do
feel
like
we
do.
Have
two
separate
you
wise.
F
I
don't
know
how
to
how
to
phrase
it
so
to
make
myself
clear
that,
like
you
cannot
re
like
my
my
feeling
is,
that
will
not
be
able
to
reuse
the
ui
for
the
issues
or
create
new
issue
for
issue
lists
for
the
feature
itself
right.
Just
like
you
need
this
new
button.
You'll
you'll
create
a
new
feature
that
will
only
have
two
or
three
or
four
attributes
on
it
and
then
then
you'll
need
to
display.
F
Like
then
we're
talking
that
we'll
have
that
detailed
view
that
will
also
show
only
a
couple
of
fields,
so
you'll
not
be
able
to
backfill
a
lot
of
this
stuff.
So
how
does
that
then
fit
into
the
issue
list
when
you'll
go
back
into
the
issue
list?
You'll?
Basically
see
everything
because
that's
an
issue,
I
guess
like
what
I'm
trying
to
say
is
like
in
old
ui,
a
feature
will
still
be
shown
as
an
issue
and
and
you'll
see
everything
on
it
right.
F
F
Is
that
okay
to
go
into
the
issue
list
and
view
the
feature
in
the
issue
details
and
it
will
basically
show
as
an
issue
or
do
we
start
actually
changing
the
issue
view
to
satisfy
the
new
types
just
to
show
the
type
to
show
all
other
stuff
on
the
issue:
detail
page
for
instance,
and
so
on
and
so
forth.
Does
that
make
sense.
F
Yeah,
I
just
want
to
understand
what
our
expectations
are
if
we
are
okay
having
every
single
type
in
there
like
the
the
features
and
whatever
else
we're
we're
moving
towards,
because
we
will
be
eventually
adding
the
requirements
and
so
on
and
so
forth.
So
you
see,
if
you
are,
we
are
okay,
mixing
in
everything
in
the
list.
That's
fine
with
me!
F
C
So
this
one
should
be
greenfield
the
new
combined
list,
or
we
could
call
that
new
feature
list.
That's
the
one
that
would
be
modified
in
the
future
to
show
any
work
item
type,
that's
defined,
but
we're
starting
with
feature
so
that
one
should
be
scalable
in
that
sense.
Eventually,
if
I
define
six
work
item
types,
they
could
all
use
that
code.
G
I
think
that's
where
the
some
of
my
confusion
was
coming
from.
Is
that,
like
after
mvc4
work
items
will
have
all
the
same
features
fields?
Whatever?
Is
the
current
issue
view
right?
So
even
if
we
haven't
migrated
epics
at
that
point,
you
can
replace
the
current
issue
detail
view
with
the
new
work
on
view.
H
G
G
A
So,
are
we
suggesting
that
we
would
have
the
issues
list,
and
this
would
be
an
item
that
you
could
create
from
the
issues
list
page
or
filter
from
the
issues
list
page,
but
the
issues
list
page
would
be
sort
of
that
initial
touch
point
for
the
user
to
create
and
interact
with
the
feature.
Work
item
is
that
right.
A
A
So
if
I'm
understanding
correctly
that
we
would
propose
that
these
two
things
would
go
out
at
the
same,
they
would
coexist
in
this
way.
That
would
be
my
only
concern.
Is
I
wouldn't
want
for
the
user
to
immediately
make
an
association
that
this
new
thing
is
a
type
of
issue
when
that
wouldn't
be
the
case,.
G
A
F
F
Like
I
think
I've
raised
it,
I've
raised
this
last
time
as
well,
but
why
can't?
We
have
a
totally
different
navigation
for
the
work
items
and
just
do
it
from
there
and
then
from
from
there.
We
we
have
instead
of
new
issue.
We
will
always
have
new
work
item
and
then
we
will
display
just
less
information
there
for
the
time
being,
because
it's
mvc,
we
will
do
all
these
crazy
stuff
and
we
can
always
just
because
it's
the
kind
of
feature
flag.
F
We
either
show
everything
that
we
have
where
we
hide
everything
that
that
we
have
or
even
have
both
the
issues
and
the
work
items.
I
guess
there
will
be
some
confusion,
because
those
are
basically
the
same
thing,
but
you
can
have
customers
try
one
and
the
other
at
the
same
time
and
kind
of
get
feedback
from
there.
I
don't
know
like
my
biggest
concern,
is
having
them
both
the
issues
and
the
work
items
in
the
nav,
which
will,
I
think,
create
confusion.
C
C
F
Building
on
top
of
the
issues
I
feel
like
there
is
a
lot
of
the
like.
I
understand
that
we
want
you
to
use
code,
but
I
think
we
can
use
code
either
way
right.
It's
just
a
lot,
a
bit
more
work.
Well,
I
don't
know
how
much
because
I'm
not
a
front-ender
and
extra,
but
it's
more
code,
because
we
need
to
add
this
new
stuff,
the
navigation
bar,
the
all
those
new
things,
but
I
don't
know.
C
C
F
Whatever
we
needed
for
that
particular
really
just
just
to
make
it
clear
like
it,
will
add
a
bit
of
a
work
on
the
back
end
right,
because
we
will
need
to
add
a
new
controller.
We'll
need
to
have
this
kind
of
few
end
points,
but
most
of
the
code
is
still
being
reused
like
we
will
reuse
the
services
we
can
by
default
filter.
Only
the
the
feature
items
right,
because
this
is
something
new.
We
don't
interfere
with
the
user
experience.
F
We
don't
interfere
with
with
what
user
expects,
so
we
can
play
around
with
a
lot
of
the
stuff
there.
I
I
think
it's
just
safer.
It
does
add
a
little
bit
of
of
work.
I
think,
on
top,
but
yeah
I'll.
Let
everyone
else
to
express
their
opinion
on
that.
I
think
that's
easier
to
understand
and
safe,
at
least
from
my
perspective,
because
I
was
struggling
a
lot
to
try
understand
how
do
we
fit
everything
in
together
on
the
existing
items.
A
G
C
We
were
discussing
around
that
sheet
and
just
that
there
would
be
like
a
migration
point
where
everyone
starts
using
the
new
one
that
goes
from
being
the
green
field
test
area
to
having
it
render
all
different
types,
including
issues,
but
that
even
if
we
make
this
green
fold
area,
we
can
still
readjust
like
figure
out.
What
is
the
right
way
to
roll
it
out
whether
everything
moves
back
onto
the
old
one
at
some
point.
G
What
is
the
transition
point
where
we
switch
issues
over
to
the
new
work
item,
detailed
view
like
like,
and
I
think
that's
where
one
of
the
things
just
recapping
this
discussion,
thus
far,
it's
clear
that
we
need
to
make
a
decision
on
how
we
roll
out
work
items,
because
I
think
that
impacts
things.
So,
let's
open
up
an
issue
to
discuss
that
async.
G
C
C
The
other
thing
to
consider
too
is
we,
haven't
really
even
talked
about
flexible,
urls
and
tracking,
and
I
know
that's
going
to
happen.
But
if
we
don't
have
this
in
a
green
field,
we're
going
to
affect
urls
for
everybody,
immediate
and
so
in
my
head,
all
along
it
had
been
greenfield
and
we
had
a
new
url
structure
on
this.
We
had
new
tracking
and
then
eventually,
we
merged
over
onto
that
new
world,
but
there's
a
lot
of
to
hold
up
behind
the
scenes.
If
we
do
start
modifying
things
like
urls
right
out
of
the
gates.