►
From YouTube: UX Weekly - 2020-11-10 - Iterations AMA
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).
B
C
D
D
Yeah
so
my
question:
let
me
try
and
figure
out
how
to
read
like
say
it.
So
iterations
is
a
two
week
block
is
my
understanding,
that's
defined
at
the
group
level
for
how
git
lab
itself
is
using
iterations.
So
how
is
an
actual
like
it?
Where
is
an
actual
iteration
defined,
not
the
two-week
block,
but
what
will
be
accomplished
in
the
two
weeks?
C
Yeah
thanks
for
the
question,
I
think
if
I
understand
the
question
the
iterations
started
around
july,
an
engineering
manager
from
plan
created
the
first
iteration
in
iterations
feature
and
they've
just
been
incrementing
plus
one.
Since
then
the
iteration
start
and
end
should
be
when
you
click
into
the
iteration
or
even
on
the
iteration
list,
it
should
say
the
start
and
end
date
for
the
iteration,
but
I'm
guessing.
I
don't
understand
your
question
totally.
D
Yeah,
so
my
I'm
wondering
like
so
say
you
have
an
issue.
Is
the
issue
scoped
to
the
two-week
iteration?
Is
it
like
the
scope
of
the
issue
supposed
to
be
what
you
are
going
to
accomplish
in
that
two
weeks
or
is
the
issue
scope
to
whatever
the
problem
is,
and
you
are
adding
an
iteration
and
then
you're
changing
the
iteration
over
time.
C
D
Mostly,
I
think
it
would
be
product
managers
would
be
looking
at
like
all
right.
We
have
this
set
of
issues.
I
see
it's
in
this
iteration.
Does
that
mean
it's
going
to
be
complete
in
two
weeks,
or
does
that
mean
I'm
going
to
keep
changing
the
iteration
as
I
need
to?
Because
the
scope
of
the
issue
is.
C
Larger
yeah,
I
think
I
think
it
would
be
where
so.
I
think
it's
it's
difficult
to
know.
I
think
if
something
is
in
scope
and
if
we're
actually
going
to
be
able
to
accomplish
it
by
the
iteration
that
we
committed
to
it's
it's
difficult
to
do
those
things
if
we
don't
have
a
regular
iteration
planning
event.
C
C
I
think
it
would
really
just
depend
on
the
team
and
like
what
they
consider
in
scope
and
out
of
scope
or
what
they
consider
too
big
or
or
just
right,
but
I
think
if
a
team
can
try
to
commit
or
a
designer
can
try
to
commit
to
making
issues
that
are
a
two-week
scope
that
over
time,
you'll
start
to
see
the
iterations
become,
for
the
issues
become
kind
of
evenly
sized.
Where
you
don't
have
these
big
complex
things,
and
then
these
little
tiny
things.
C
We
have
things
that
are
kind
of
a
happy
medium
and
we
have
a
more
of
a
continuous
flow.
So
the
iteration
as
a
smaller
constraint
than
a
milestone,
is
to
encourage
more
work.
That's
like
right,
sized
or
just
the
right
size.
So
they
don't
go
on
for
a
really
long
time,
because
they're
too
big
in
scope.
C
I
think
the
closest
thing
that
we
have
is,
if,
if
you
go
to
slide
8
and
click
into
iteration,
9,
there's
a
link
at
the
bottom
of
slide.
Eight
it'll
consideration,
nine
and
if
you
scroll
through
that,
you'll
see
examples
where
there's
validation,
issues
that
designers
have
created
and
closed
in
terms
of
like
an
example
of
like
here
was
here
was
the
larger
issue.
Then
here's
how
it
broke
down
and
like
actually
visualizing
that
and
showing,
and
then
this
went
into
this
iteration
that
went
into
the
other
iteration.
E
E
So
the
plan
team,
the
then
called
portfolio
management
team,
used
iterations
iterative
approach,
and
you
know
they
called
it
iterations
for
epic
swim
lanes,
and-
and
they
did
that
like
to
answer
the
question
that
somebody
asked
previously
what
the
what's
the
problem.
This
is.
So
what
problem
this
is
solving
is
that,
like
an
iteration,
doesn't
always
overlap
like
it's
not
always
the
same
time
frame
as
gitlab
release,
which
is
you
know
a
month,
and
here
I
believe
they
they
were
using
a
week
long
well,
not
two
week
long
iterations.
E
C
That
is
a
great
example.
I
think
the
difference
here
is,
or
one
thing
to
note
is
the
the
issue
actually
has
iterations
six
and
seven
sort
of
written
out
in
the
issue
description
I
think,
to
to
dog
food
iterations.
We
would
actually
like
point
to
the
iteration.
That's
the
iteration
object
right,
the
one
that
starts
on
92
2020.
C
D
F
And
mike,
I
think,
I'd
like
to
to
share
my
example
and
see
if
this
helps
clarify
for
tori
at
all
how
it's
kind
of
played
out
for
me
I'll
I'll
share
my
screen.
I
can
post
the
issue
in
the
docs
in
a
minute
so
as
we
were
progressing
through
the
validation
track,
we
had
this
big
issue
that
was
sitting
in
workflow
design
and
it
wasn't
clear
necessarily
like
how
are
we
moving
this
forward
because
it
was
just
sitting
there
workflow
design.
It
was
seeing
all
this
activity,
but
nothing
was
progressing.
F
So
what
I
did
was
I
promoted
it
to
an
epic
because,
as
I
was
like
understanding
the
scope
more
as
I
was
getting
more
involved
with
the
problem,
it
was
clear.
There's
a
lot
more
work
to
be
done,
and
so
I
broke
this
down
into
smaller
chunks
of
work
that
I
was
going
to
try
and
do
over
two
week
increments.
So
I
went
from
like
low-fi
to
taking
feedback
to
converging
on
the
solution.
F
F
B
G
F
Yeah,
I
don't
think
I
have
one
up
right
now,
but
they
were
definitely
times
where
I've
marked
these
as
like
hey.
This
is
blocking
other
issues
from
moving
forward,
because
I
need
to
converge
on
like
initially.
This
was
blocked
by
this
one,
because
it
needed
to
have
the
solution
created
before
we
could
go
validate
something,
but
that
just
requires
a
little
bit
more
foresight
and
planning.
But
I
don't
have
one
off
top
of
my
head
that
I
could
just
quickly.
A
F
Thank
you
I'll
add
the
notes.
People
can
go
check
it
out.
I'll
note
that,
like
those
ones
that
I
was
showing
were
quite
small
like
there's,
really
not
a
whole
lot
of
data
in
them,
I'm
trying
to
be
better
about
actually
updating
those
sub
issues,
as
opposed
to
just
putting
all
the
data
in
epic
but
opportunity
for
improvement.
H
Yep
yeah
thanks
austin.
That
was
very
helpful
to
see
some
more
examples
and
just
see
all
more
examples
in
general.
I
think
is
really
helpful.
One
question
I
had
when
I
started.
I
wanted
to
try
to
dog
food
it
maybe
a
couple
weeks
ago
and
I
apologize
if
this
has
been
answered
somewhere
in
the
handbook
or
in
the
documentation
somewhere,
but
I
wasn't
sure
about
the
naming
of
the
iterations.
H
Do
I
create
my
own
name
iteration,
so
I
saw
on
gitlab.com
the
project
had
some
iterations
that
already
had
like
specific
custom
names,
but
then
going
on
to
the
gitlab
org
project.
There
were
just
iterations
that
looked
like
they
were
just
automatically
created,
so
it
just
said,
like
you
know,
gitlab,
you
know
number
two
number
three
you
know
and
so
on.
So
I
wasn't
sure
then,
and
then
I
tried
to
create
my
own
iteration,
so
I
wasn't
sure
should
I
be
using
the
ones
that
I
see
in
that
list.
H
You
know
in
in
my
side
sidebar
panel
or
should
I
be
creating
my
own
and
then
I
realized
that
a
lot
of
other
you
know
designers
were
already
using
some
issues.
So
I
didn't
want
to
break
anything,
so
I
just
kind
of
left
it
alone.
Yeah.
I
see
there's
some
answers
there
already
that
someone
posted
but
yeah.
That
was
my
main
question
about.
How
does
that
all
work
together.
J
My
question
followed
up
right
after
years,
though
about
because,
if
we're
gonna
have
to
use
the
one
that's
already
defined,
do
we
have
to
use,
for
example,
iteration,
13
or
14?
That
doesn't
make
any
sense
if
this
is
a
new
project
for
my
stage
or
my
group,
why
am
I
what
happened
to
the
previous
13
iterations?
Where
can
I
go
see
those.
B
C
Think
that
jackie
made
a
issue
jackie
and
I
were
talking
on
the
phone
yesterday
and
we
both
agreed.
It
was
more
intuitive
if
the
iterations
were
named
after
the
date
range,
and
this
is
actually
what
pivotal
tracker.
Does
you
don't
even
have
to
create
the
iteration
it's
just
there
and
it's
named
after
a
date
range
seems
the
most
intuitive
and
I
think,
donald
who
was
as
the
first
dog
fooder,
has
a
little
bit
of
stake
and
like
what
it's
called.
C
G
H
Yeah,
I
think
so
I
think
that
would
be
really
helpful.
I
was
a
little
confused
by
that.
You
know
if
I
needed
to
see
if
I
started
a
new
project.
My
my
instinct
was
to
just
start
with
iteration
one
and
then
just
go
from
there,
and
then
I
realized
that
iteration
one
has
been
already
closed
and
has
already
passed
so
seeing
the
due
date.
F
B
L
B
L
I
still
oh,
this
sounds
weird
anyway.
I
still
have
a
little
bit
of
confusion
in
austin's
example.
That
makes
sense
to
me
that
there
was
an
issue.
It
was
really
complicated.
He
promoted
to
an
epic
totally
following
that.
I
see
the
little
issues
that
were
created,
and
that
makes
sense
too.
Some
of
them
are
labeled
as
iterations,
and
one
of
them
isn't-
and
I'm
is
this
about
dog,
fooding,
iterations
of
feature
or
just
iterating
in
that
way,
creating
an
epic
breaking
things
out
into
smaller
issues.
C
C
I
It
looks
like
I'm
next
so
see,
austin.
Seeing
your
example
is
really
really
helpful.
So
I
won't
reread
all
of
my
question
but
a
question
to
anyone.
Who's
used
the
iteration
feature,
I
guess,
is:
how
are
you
managing
and
maintaining
a
single
source
of
truth
with
all
of
this
granular
issue
creation,
and
how
are
you
making
sure
that
the
right
conversations
are
happening
in
the
right
place
if
an
engineering
team
wants
to
collaborate
or
a
product
team
wants
to.
F
Yeah
I
can
yeah,
I
can
revisit
what
I
was
saying
earlier.
I'm
still
trying
to
figure
that
out
too
initially,
I
was
just
trying
to
boil
everything
up
into
like
one
parent
issue,
which
then
became
the
epic,
so
I'm
trying
to
keep
the
low
level
details
in
the
iteration
of
a
specific
issue
and
then
perhaps
like
those
outcomes
or
the
high
points
of
the
decision
surface
into
the
parent
epic
for
those
issues.
F
So
maybe
you
have
all
this
discussion
around
the
interface
within
one
issue
and
then
your
finalized
solution
is
what
ends
up
making
up
into
the
epic.
Definitely
what
I've
seen
over
time
is
issues
that
are
in
the
validation
track,
just
tend
to
grow
and
grow
and
grow.
At
least
it
has
for
compliance,
which
then
creates
this
massive
issue
at
the
end
of
the
validation
track,
which
makes
it
really
hard
for
the
development
team
to
sift
through
everything,
as
opposed
to
trying
to
whittle
it
down
to.
B
I
I
It
was
a
huge
issue,
it's
very
old
also,
but
we
kind
of
just
laid
out
the
experience
that
we
believe
is
like
the
next
step
right,
which
is
a
lot
of
changes,
but
we
let
the
engineers
we
kind
of
guided
them
in
saying,
like
a
feasible
step,
one
a
feasible
step,
two
in
a
feasible
step,
three
and
put
requirements
in
those
steps
and
then
kind
of
let
them
break
down
for
implementation
as
long
as
there's
meeting
those
requirements.
So
we
don't
have
like
an
incomplete
experience.
I
C
I
think,
if
that
works
for
your
team
andy
keep
on
keeping
on
no
we're
not
asking
anyone
to
change
their
process.
Yeah!
It's
it's
more
just
dog
food
iterations
feature
and
maybe
you'll
find
something
new
pops
up
from
using
it.
Maybe
not,
but
also
don't
don't
break
anything
just
to
dog
food
it
if
something's
working
for
you.
B
A
So
what
are
all
those
little
steps
that
get
you
to
that
and
then
once
you
give
them
that,
then
they
can
break
that
down
into
how
they
want
to
implement
that.
Just
like
you
said
because
yeah
I
don't
know
how
the
development
team
needs
to
break
down
their
implementation
tasks,
and
I
would
never
presume
to
tell
them
how
to
do
that.
B
K
K
So
please
do
continue
to
put
that
feedback
in
that's
really
going
to
be
beneficial
for
us,
as
we
continue
to
add
to
this
feature-
and
I
actually
would
love
to
schedule
a
couple
of
quick
calls
with
austin
and
tori
and
a
few
other
folks
that
I've
made
some
notes
about
just
to
get
a
little
bit
deeper,
feel
for
how
you're
using
these
features.
So
just
look
for
those
coming
up
on
your
calendar
scene
and
thank
you
so
much
to
everybody
who
has
been
dog
fooding
this
and
providing
that
feedback.
It's
really
really.