►
Description
Thinking about how we use the first iteration of.. Iterations.
A
Yeah,
so
maybe
like,
can
you
walk
through
how
you
used
to
plan
iterations,
because
I
know,
for
example,
in
that
swim
lanes,
mvc
the
epic
swim
lanes
of
ac
issue?
I
know
you
broke
things
down
into
iterations
kind
of
manually
and
now
you're
doing
iteration
planning,
I
guess
outside
of
get
lab,
but
then
also
within
iterations,
so
kind
of
like
walk
through.
Maybe.
B
B
Putting
everything
in
narrations
so
what's
the
best
way
to
to
do
this,
let
me
start
off
with
showing
you
our
iteration.
B
Issue-
and
I
will
show
you
the
issue
from
last
iteration,
because
this
one,
like
we
just
created
this
john,
just
created
this
for
product
planning,.
A
B
B
It
is
two
weeks
now,
instead
of
one
week,
yep,
okay,
okay,
so
what
we
do
this
is
within
the
plan
project
is
we'll
create
two
of
these
fortnightly
iteration
issues,
one
for
product
planning
and
one
for
project
management,
typically
either
john
or
myself,
and
then
jake
or
myself
create
the
issue,
and
we
use
this
as
kind
of
our
it
kind
of
replaces
the
planning
issues
that
we
used
to
have
so
I'll
just
go
through
the
highlights
of
of
this
issue
real
quick.
B
We
do
a
quick
recap
of
the
last
iteration
there
any
of
the
goals
we
hit.
Anything
that
is
carry
over
anything
that
we
didn't
finish
in
the
last
iteration.
I
mean
right
now
we're
saying
if
something
doesn't
get
too,
I
think
it's
still.
If
something
doesn't
get
to
review,
we
want
to
get
to
a
place
where
it
only.
B
Yeah
we're
not
at
that
small
of
a
cycle
time,
yet
we
we're
just
saying
if
it's
in
review
it
counts
as.
A
B
Actually,
I
think
it's
if
it's
in
maintainer
review,
if
it's
an
initial
review,
we'll
still
carry
it
over,
but
if
it's
in
maintainer
review
or
it's
close
to
being
merged
in
then
we'll
go
ahead
and
count
as
being
done.
B
It
does
carry
over
and
then
we
start
going
through
what
is
new
for
the
next
iteration,
and
this
is
primarily
just
features,
so
any
features
that
we
can
commit
to
in
the
next
iteration
we'll
put
in
here
john,
goes
through
and
puts
all
the
back
in
ones
that
we've
committed
to
I'll
go
in
and
do
the
front-end
ones
on
the
front-end
side,
because
what
I
want
to
do
is
get
to
a
point
where
our
feature
issues
are
two-week
or
iteration
chunks
of
work,
and
then
I
can
just
I
could
just
say
so
say
we
have
like
three
front-end
engineers
on
project
management.
B
B
A
A
Okay
right
and
you
kind
of
know,
the
upcoming
iterations
might
match
that
theme
as
well.
So
you
might
know
that
let's
say
flory
is
working
on
something,
and
you
know
that
these
two
iterations
relating
to
that
theme
are
upcoming.
So
you
might
kind
of
be
able
to
understand
what
she's
going
to
be
working
on
yeah.
B
Okay,
so
then,
once
we
have
this
list
completed
and
I'll
normally
work
with
the
engineers,
either
in
101s
or
in
our
slack
channel,
on
what
they're
going
to
take
on
in
the
next
iteration.
But
once
we've
completed
this
this
table
here
I'll
just
go
into
the
issues
and.
B
And
then
I
will
update
the
iteration
to
whatever
the
upcoming
iteration
is
so
this
one
looks
like
was
part
of
the
carryover,
so
if
it
had
iteration
10
I'll
just
go
in
and
change
it
to
iteration.
B
For
now,
we
do
have
one
more
one
more
step
in
there,
because
we
don't
have
iteration
metrics
in
product.
Yet
we're
doing
a
lot
of
that
manually
within
a
within
a
spreadsheet.
B
So
we've
only
been
doing
this
for
the
past
couple
of
iterations,
but
we
have
a
a
sheet
here:
a
new
sheet
for
each
iteration
and
at
the
beginning
of
the
iteration,
we'll
come
in
and
add
all
of
the
issues
that
we
commit
to
and
we'll
put
in
some
basic
information
here
and
then
at
the
end
of
an
iteration.
B
B
That
must
be
hard
because
I
feel
like
I
use.
I
say:
google
a
lot.
B
A
B
Yeah,
but
so
I
we
transferred
that
from
the
csv
over
to
psi
sense
and
then
we're
able
to
have
some
or
to
add
some
basic
basic
analytics
through
sisense
that
way.
Okay,
eventually,
you
want
to
get
to
a
point
where
a
lot
of
those
charts
are
within
the
product
and
we
already
have
I'll
go
into
the
iterations.
B
Now
we
have
some
basic
charts,
but
there's
no
filtering
or
anything
so
this
this
includes,
like
the
iterations
page
here,
includes
issues
for
the
entire
group,
actually
where
it
is
just
a
project,
but
you
can't
filter
it
by
just
like
the
plan
stage.
So
the
charts
that
do
show
up
or
that
will
show
up
here-
are
not
valuable
yet
because
it's
like
essentially
the
entire
company's
metrics.
B
B
So
there's
a
couple
issues:
sorry,
just
real,
quick
there's
a
couple
issues
on
improvements
we
want
to
make
to
this
page
one
is
to
add
the
the
charts
and
I
think
that
is
actually
already
merged,
and
we
just
need
to
turn
on
the
feature
flag.
But
again
that
will
show
the
numbers
for
for
all
of
git
lab,
there's
an
issue
to
filter
it,
but
then
there's
also
an
issue
for
down
here
to
be
able
to
group
by
a
specific
label.
B
A
B
At
least,
if
we're
able
to
group
it
by
and
by
like
the
group
labels,
then
we'll
that'll,
even
even
just
that'll,
be
a
lot
more
valuable
than
this
is.
A
B
So
I
want
to
see
and
it'd
be
nice
if
we
had
it
by
and
that's
what
the
burn
up
and
burn
down
church
will
show,
but
even
just
a
basic
burn
down
chart.
So
I
can
come
in
like
halfway
through
an
iteration
and
see
how
see,
if
we're
on
track,
to
complete
to
complete
everything
within
that
iteration
or
how
much
we
have
left
in
that
iteration
that'd.
Be
super
helpful,
also
stuff
like
seeing
what
our
what
our
velocity
is
for
an
iteration.
B
We
don't
we
don't
have
that
in
product,
yet
we
do
that
for
milestones
off
of
weight
in
size
sense,
but
it'd
be
nice
to
get
that
information
at
an
iteration
level,
because
I
think
we
want
to
move
a
lot
of
our
planning
to
the
two-week
iterations
instead
of
the
month-long
milestone
or
release.
B
B
Those
are
the
main
benefits
planning
wise.
It's
a
lot
easier
too,
because
it's
just
less
work
that
you're
planning
for
so
those
are
some
of
the
main
benefits
I
think
of
smaller
iterations.
A
That's
a
lot
of
benefits.
Do
you
have
a
an
example
of
where
breaking
work
down
into
iterations
helped
us
move
a
little
faster
or
maybe
understand
something
was
like
blocked
or
flagged
something
up
more
quickly.
B
B
I
think
the
swim
lanes
work
was
was
a
good
example,
but
that
may
have
also
been,
I
think,
having
it
split
up
into
iterations,
caused
us
to
break
down
things
and
come
up
with
a
plan
as
opposed
to
well.
Maybe
we
can
get
all
this
stuff
done
within
the
month.
A
B
Especially
the
ones
that
I
know
I've
been
at
yeah
like
I've,
been
I've
been
on
this
issue
like.
B
Should
probably
just
bookmark
this
this
issue
yeah
yeah,
so
here
is
the
iteration
schedule
here
I
think
before
we
had
the
schedule
laid
out,
we
just
said
you
know:
let's
try
to
get
swim
lanes
done
in
this
milestone.
B
Like
map
on
how
to
how
to
go
about
getting
these
done,
and
there
were
some
cases
where
you
know
we
got
to
an
iteration,
we
worked
on
that
and
that,
like
objective
ended
up
taking,
ended
up
being
more
work
than
we
had
already.
Then
we
had
thought
about,
and
that
was
okay,
because
then
we
were
able
to
say
you
know
this
is
going
to
take
another
iteration.
B
Let's
just
push
everything
in
the
upcoming
iterations
a
a
another
iteration
or
we
could
have
adjusted
something
like
pulled
something
up
so
that
we
were
working
on
it
in
parallel
with
another
objective,
from
a
from
a
from
a
sooner
iteration.
So
there's
just
a
lot
more
flexibility
when
we
had
things
chunked
into
these
small
iterations.
B
A
B
Yeah
yeah
yeah,
especially
for
cases
like
this,
like
ideally
a
lot
of
what
we
work
on.
We
can
work
on
in
parallel,
but
there
are
some
cases
where
it
doesn't
where
that
doesn't
work,
because
there
are
dependencies
so
yeah
this.
This
really
laid
out
where
we
were
able
to
lay
out
like
the
order
that
we
were
able
to
do
things
and
saying
that
you
know
this
is
this
is
something
that
a
lot
of
future
things
are
going
to
be
dependent
on.
B
So
this
is
really
something
that
we
really
that
we
need
to
get
done
in
this
in
an
earlier
iteration,
as
opposed
to,
as
opposed
to
you
know,
pushing
it
back
to
a
future
iteration.
B
Yes,
we
do,
but
I
don't.
B
Yeah,
no,
we
do
whenever,
because
we
were
always
pretty
good
at
at
using
like
the
related
related
to
box,
but
once
we
got
the
the
blocked
by
and
the
blocked
the
blocked
and
the
blocked
by
widget
like
we
were
able
yeah,
we
started
using
that
more.
B
I
don't
know
if
we
use
it
enough,
like
after
the
fact,
especially
on
the
like
you
work
on
something,
and
you
see
that
it
blocks
multiple
multiple
downstream
issues
like
I
don't
think
we
do
a
good
enough
job
of
after
that,
after
the
first
dependency
is
cleared
out,
going
to
all
the
other
issues
and
updating
them
and
saying
hey.
This
is
not
blocked
anymore.
We
can
work
on
this.
Now
we
probably
need
to
figure
out
a
better
way
of.
B
This
blocker
is
this
blockers,
or
this
thing
is
no
longer
blocked,
but
in
general
I
think
we
do
do
a
pretty
good
job
of
of
using
that
widget.
A
Yeah,
I
noticed
some
cool
things
recently,
where
it's
like
it
actually
pops
up.
Saying
something
saying:
are
you
sure
you
want
to
close
this
issue
right
like
that?
Yeah?
That's,
that's
awesome,
that's
cool!
So
how
can
you
see
design
helping
y'all
with
this
and
breaking
things
down
into
iterations
or
even
making
our?
I
guess
our
design
process
more
visible
through
iterations.
A
B
B
Well,
how
do
you
think
we
can
use?
We
can
use
this
product
because,
ideally
you
know
we're
working.
B
Like
the
way
I
envisioned
working
with
design
is
like
the
majority
of
work
is
going
to
be
within
the
iteration
that
we
commit
to
building
something,
but
for
most
features
for
more
most
issues
like
there's
going
to
be
a
decent
amount
of
early
on
prep
work
like
prep
work
as
far
as
the
designs
are
concerned,
so
it'd
be
nice.
B
If
we
had
design
working
like
an
iteration
ahead
of
development
to
get
at
least
the
at
least
the
initial
designs
done,
but
then
yeah,
I
also
don't
want
because
I've
seen
this
fail
in
the
past,
where
we
have
a
completely
separate
design
team
that
tries
to
work
ahead
of
the
development
but
then
they're
working
on
something
and
then
it's
kind
of
just
thrown
over
the
fence
to
developers
and
then
there's
not
a
whole
lot
of
communication
like
when
you
have
those
handoffs
there's
not
a
whole
lot
of
communication.