►
From YouTube: Multi-team planning with GitLab Ultimate
Description
Plan direction: https://about.gitlab.com/direction/plan/
00:00 - Intro
00:15 - Company Scenario
02:20 - Groups, Subgroups, Projects
03:00 - Epics/Issues
03:50 - Labels - Scoped / Regular
06:00 - Time box - Milestones / Iterations
08:35 - Value Streams with Epics, Sub-Epics (Features), Issues
10:18 - Epic Start/Due Dates
11:57 - Epic Boards
13:31 - Issue Boards
15:40 - Roadmap
17:40 - Team Planning
18:44 - Team Board
19:00 - Team Board (WIP)
19:28 - Build Track Board (Current Iteration)
20:45 - Subgroup Work Visibility
21:46 - Issue Details
22:55 - Figma Integration
24:15 - Issue List View
25:06 - Requirements Management
26:14 - Create MR from Issue
28:50 - Merge Requests
31:15 - Issue Templates
32:45 - Reporting (Insights)
34:40 - Reporting (Value Stream)
37:11 - Conclusion
A
A
Here's
a
scenario
we're
going
to
talk
through
today.
We
have
an
awesome
company.
This
company
has
three
value
streams:
let's
say
consumer
products,
services
logistics,
each
value
stream
has
cross-functional
squads
that
has
all
the
stable
counterparts
necessary
to
deliver
working
software,
customer
value
and
business
outcomes.
A
So
this
is
a
topology
of
the
organization
in
the
teams.
Awesome
company
breaks
down
their
work
this
way
where
they
have
a
highest
level,
epic,
which
they
sort
of
run.
Usually,
you
know
the
six
months
period
and
they
plant
the
portfolio
level.
Those
get
decomposed
into
capabilities
capabilities
are
decomposed
into
features
and
features
are
decomposed
in
the
lowest
level
thing
called
task
stores
bugs
and
maintenance.
A
They
plan
biannually
at
the
portfolio
level
and
that's
where
they
kind
of
decide
what
epics
they're
going
to
work
on.
They
plan
their
capabilities
and
features
for
releases
on
an
eight-week
schedule
and
the
the
actual
squads
are
autonomous
and
can
pick
if
they
want
to
do
iteration
based
or
time
box
based
planning
or
if
they
want
to
use
a
pull
system
like
kanban.
A
A
You
validate
the
solutions
and
the
problems,
and
then
you
work
with
your
stable
counterparts
to
refine
breakdown,
estimate
your
work
items
after
that,
it's
ready
to
be
scheduled
into
the
actual,
build
track
where
they
go
into
the
backlog,
which
is
this
ready
state
engineers
pull
them
into
progress
when
they're
ready
to
start
and
when
they're
done
they
go
into
a
review
process.
You
know
qa
checking
stuff
out
on
staging
when
it
has
actually
been
approved
and
the
merge
request
has
been
merged.
A
A
I've
gone
ahead
and
set
up
a
lot
of
the
structures
just
to
save
time
and
watching
a
bunch
of
mouse
clicks,
but
within
git
lab
we
have
something
called
groups.
I've
created
this
group
for
awesome
code,
which
is
considered
the
top
level
company
group
within
that
I've
created
subgroups
for
each
of
their
different
value
streams.
So
we
have
logistics
that
has
squads
enf
in
it.
A
We
have
consumer
products
that
has
squad
c
and
d,
but
those
squads
also
just
work
across
both
of
their
projects
web
app
mobile
app
and
then
we
have
a
services
group
that
is
kind
of
handles
the
api,
the
custom
corporal
and
some
things
like
that.
I've
also
created
a
project
within
awesome
code
for
ops
that
has
some
shared
settings.
There's
also
wiki
only
project
to
track
sort
of
some
wiki
related
and
documentation.
A
The
thing
to
understand
about
how
groups
and
projects
work
in
gitlab
is
that
the
hierarchy
sort
of
defines
how
information
flows
up
and
down
the
hierarchy.
So
there's
two
sort
of
main
objects
in
gitlab,
there's
epics.
There
are
issues
within
ultimate.
You
can
have
multi-level
episodes
here
in
a
minute
and
then
issues
are
the
lowest
level
kind
of
work.
Item
issues
live
at
the
project
level.
Epics
live
at
the
group
level
issues
if
from
squads
enf,
for
example,
would
flow
up
and
be
visible
in
logistics.
A
They
would
flow
up
and
then
also
be
visible
at
awesome
code.
So
osmoco
has
this
sort
of
ability
to
look
across
all
of
their
groups
and
projects
and
all
the
work
items
that
are
there.
You
also
have
the
ability
to
create
things
within
austin
code
that
flow
down,
so
you
can
create
epics
and
awesome
code
which
are
visible
within
logistics
so
that
you
can
assign
sub-epics
or
child
epics
and
issues
to
those
and
sort
of
build.
A
This
sort
of
hierarchical,
workout
structure
that
we
talked
about
before
I've
also
created
within
this
top-level
group
labels
labels
are
a
pretty
powerful,
primitive
with
a
gitlab
that
allows
you
to
have
a
pretty
robust
taxonomy
for
your
work
items.
It's
helpful
for
reporting
for
managing
kind
of
what
type
of
work
it
is
workflows
and
all
sorts
of
other
things.
There
are
two
kinds
of
labels
in
gitlab.
There
are
normal
labels,
which
you're
probably
used
to
and
scope.
A
Labels
are
something
that
is
going
to
kind
of
be
unique
to
gitlab
and
a
scope
label,
acts
sort
of
like
a
custom
field
and
that
an
issue
or
an
epic
can
only
have
one
label
of
a
given
key
at
a
time.
So,
if
I
have
an
issue
with
capability,
one
refine-
and
I
I
try
to
add
this
capability
to
review
label.
It
will
automatically
remove
this
other
first
label
and
apply
the
second
one.
A
A
I
also
set
up
scope
labels
to
kind
of
visualize
and
manage
that
workflow
that
awesomeco
has
so
things
go
into
triage.
They
go
into
design,
they
encode
the
validation,
refinement,
ready,
that's
the
refinement
track,
and
then
we
get
into
the
build
track
where
we
have
some
workflow
labels
for
that
as
well.
A
So
labels
are
great
because,
if
you
create
them
at
a
higher
level,
it's
a
way
to
standardize
the
taxonomy
of
your
work
items
downstream,
so
we're
at
awesomeco-
and
I
created
the
labels
there.
If
I
were
to
go
down
and
look
at
squad
for
example,
and
go
look
at
their
label
lists
they're
going
to
have
all
the
same
labels
that
we
defined
above
squad
f
can
also
create
their
own
labels
if
they
want,
if
they
want
to
break
from
what
is
sort
of
the
standards
or
do
things
a
little
bit
outside
of
the
lines.
A
But
this
is
a
great
way
to
simplify
management
of
your
labels
across
all
of
your
subgroups
and
projects,
and
also
promotes
consistency
in
terms
of
how
like
planning,
cadences
work
in
gitlab,
we
have
two
kind
of
constructs:
awesomeco
has
their
eight-week
release
cycle
and
for
that
I've
created
milestones.
So
milestones
can
have
time.
Dates
start
end
dates
or
they
cannot.
You
can
use
them
they're
pretty
flexible,
but
in
this
case
I'm
going
to
use
them
to
manage
my
releases.
A
So
I've
created
a
release
for
each
of
the
upcoming
eight
weeks,
eight
week
cycles
and
so
we're
out
24
weeks
at
this
point,
and
when
you
look
at
a
milestone
detail
view,
you
have
burn
down
and
burn
up
charts.
If
you
have
start
and
end
dates,
you
can
filter
these
charts
by
issue
count.
You
can
filter
them
by
issue
weight.
You
can
see
a
list
of
the
issues
that
are
associated
with
this,
given
milestone
or
release
and
also
basic
status
on
them.
A
If
they've
been
unstarted,
if
they're
ongoing
or
if
they've
been
completed,
we
also
roll
other
things
up
like
time,
tracking
reporting
and
overall
progress,
completion
rates
on
your
milestones,
and
so
that's
your
kind
of
eight-week
cycle
and
then
for
those
teams
that
are
doing
the
two-week
cycles.
We
have
something
called
iterations
and
so
an
issue
can
belong
to
both
a
milestone
and
iteration
at
the
same
time.
So
this
is
a
feature
that
is
up
and
coming
it's
behind
a
feature
flag,
but
I'll
go
ahead
and
show
it
off
because
it'll
be
live
in
gitlab.com.
A
Soon
I
mean
it
is
live
just
by
the
feature
flag.
That's
enabled
for
this
group,
but
it's
something
called
iteration
cadences
and
what
that
is
is
like
each
cadence
can
be
created
and
it's
just
a
basically
a
collection
of
iterations.
When
you
create
it,
you
can
add
a
title.
You
can
denote
that
you
want
to
automatically
schedule
upcoming
iterations.
You
pick
the
start
date
of
your
first
iteration
how
long
in
weeks
each
iteration
is
supposed
to
be.
A
So
if
you
finish,
your
first
iteration
gitlab
will
automatically
create
the
fifth
iteration
right
if
you
want
to
always
maintain
four
in
the
future,
so
this
pretty
much
takes
away
all
the
headache
with
moving
issues
from
one
iteration
to
the
next,
creating
new
iterations,
ending
iterations.
It
pretty
much
makes
that
painless.
A
The
other
nice
thing
about
this
is,
if
you
have
lots
of
teams
that
are
sharing
one
group,
you
can
have
multiple
different
cadences
that
all
run
on
their
own
schedules.
So
here
we
can
see
these
three
squads
run
every
two
weeks,
but
squad
d.
They
want
to
have
three
week
iterations,
which
is
fine
and
they're
able
to
do
that
now.
A
A
Those
can
further
be
decomposed,
as
we
mentioned
down
into
features,
so
we
need
to
create
the
account
flow
and
within
that
we
also
need
to
manage
some
web
app
user
settings.
But
let's
say
that
we
want
to
decouple
web
app
user
settings
from
create
account
flow.
You
can
just
drag
and
drop
your
epics
to
re-parent
them
right
within
this
view.
So
it's
a
great
way
to
kind
of
move
things
up
and
down
to
reorganize.
A
You
can
also
drag
and
drop
any
of
your
epics
to
reorganize
them
if
you
want
to
visually
visualize
it
differently
or
sequence,
things
out
in
a
different
way
or
change
the
parenting
structure
from
when
this
is.
In
this
view
you
can
also
add
new
issues
and
you
can
create
new
epics
as
well.
So
let's
say
I
missed
some
scope
when
I
need
to
add
something
for
the
logistics
group.
I
can
go
down
here.
A
Select
a
group
that
I
want
to
create
the
epic
in
and
add
some
reporting
for
the
supply
chain
and
create
that
epic,
so
this
will
go
ahead
and
create
this
epic
within
the
this
and
nested.
Under
this
1.0
launch,
I've
created
a
logistics
group,
so
it's
visible
there,
but
it's
also
automatically
rolled
up
into
this
higher
level.
1.0
launch
that
we
need
to
do
the
interesting
thing
about
epics
is
there's
two
different
ways
that
they
can
manage
and
be
scheduled
in
terms
of
their
dates.
A
You
can
set
some
fixed
dates
if
you
want-
and
this
is
basically
where
you're
going
to
manually
set
the
start
date
manually,
set
the
due
date
or
epics
have
something
called
inherited
dates
and
the
way
that
works
is.
It
looks
across
all
of
the
issues
that
are
part
of
this
epic,
all
the
way
down
the
lowest
level
kind
of
determining
your
tasks,
your
maintenance
items,
your
bugs
your
stories
and
it's
going
to
pick
the
early
start
date
based
on.
A
If
that
issue
has
a
due
date
assigned
iteration
or
a
milestone
and
that
milestone
start
date
and
then
it's
going
to
look
at
the
latest
end
date,
it
can
find
across
all
of
those
different
time
ranges
and
that's
how
it
kind
of
dynamically
keeps
us
up
to
date.
So,
in
terms
of
planning
breakdown,
you
start
with
your
scope
and
you
decide
what
you
need
to
do
to
call
this
complete.
What
you
think
you
need
and
then,
as
a
team,
starts
to
break
this
down
and
plan
it
into
releases
and
into
iterations.
A
And
you
have
this
very
rich
kind
of
audit
history
for
every
single
change
that
ever
happens,
the
epic
and
who
changes
it
and
what
they
do.
Epics
also
have
discussions,
so
you
can
have
threaded
discussions
directly
within
the
epic
and
you
can
see
what
has
changed
within
the
description
as
you,
edit
over
time,
so
anytime,
anything
ever
changes
on
this.
A
The
next
thing
to
do
is
thinking
about
how
we
might
want
to
plan
and
manage
these
going
on.
So
there's
two
different
kinds
of
boards
within
gitlab.
There
is
an
epic
board
and
you
can
have
as
many
boards
as
you
want
to
group
levels.
So
I've
created
one
board
to
kind
of
represent,
showing
my
different
feature
level
epics
broken
down
by
component,
which
is
one
of
those
spoke
labels
we
set.
You
can
visualize
progress
directly
here
as
well.
A
You
can
kind
of
see
what
all
scope
is
going
into,
which
parts
of
your
overall
system
or
value
stream.
I've
also
created
a
board
that
has
kind
of
a
light
workflow
just
for
capabilities.
So
as
we
want
to
create
new
capabilities,
we
want
to
break
them
down.
You
can
actually
move
your
epics
through
their
own
workflow
independent
of
the
the
issues,
and
this
is
a
great
way
for
product
managers
or
executives
to
sort
of
manage
the
workflows
for
their
higher
level
work
items.
A
I've
also
created
a
board
that
has
lists
based
on
the
different
types
or
the
different
levels
of
work
item.
So
if
I
want
to
quickly
visualize
it
that
way,
I
can
do
it
within
this
board
view,
and
I've
also
created
a
board
that
has
lists
for
each
of
the
squads,
so
I
can
see
which
squad
is
working
on
which
feature,
and
I
can
also
see
the
completion
progress.
So
this
is
one
view
that
you
can
use
to
slice
and
dice
your
epics
and
kind
of
visualize
them
in
different
ways.
A
A
Let's
start
with
the
first
kind
of
track
that
we
talked
about
and
that's
the
refinement
track.
I've
scoped
this
board
to
have
no
milestones,
so
it's
only
gonna
show
me
issues
that
haven't
already
been
scheduled
into
an
upcoming
release.
This
is
great
for
doing
things
like
triaging
new
issues.
If
the
new
issue
gets
opened,
it's
gonna
show
up
in
this
triage
list,
based
on
some
of
the
templates
that
I
set,
which
I'll
show
you
in
a
little
bit,
and
this
lets
me
kind
of
move
things
through.
A
If
I
know
it's
just
a
bug
and
we
don't
need
design,
I
can
actually
move
this
all
the
way
into
refinement,
and
what
this
does
is
it's
going
to
be
a
signal
to
the
engineers
that
they
should
probably
jump
in
and
so
every
week
my
engineers
they'll
look
at
our
kind
of
breakdown
list
or
refinement
list
and
they'll
kind
of
see
that
as
a
signal
that
they
need
to
start
estimating
and
breaking
down
issues
into
implementation
tasks.
Let's
say
as
soon
as
a
bug
is
ready
to
go
and
it
gets
weighted.
A
A
So
here's
that
bug
that
we
talked
about-
and
we
can
see
that
it's
right
with
the
ready
label
this
one
that's
still
in
triage-
is
not
ready.
So
I
don't
want
to
schedule
that
out,
but
one
of
the
nice
things
you
can
do
with
this
board
is
you
can
create
lists
based
on
milestones,
so
you
have
four
different
kind
of
basic
lists
that
you
can
create
on
boards
right
now:
there's
label
assignee,
milestone
or
iteration.
A
So
boards
are
a
lot
more
than
just
managing
workflows
or
issues
they're,
actually
very
powerful
for
managing
your
entire
backlog
and
for
doing
release
and
iteration
planning.
So
in
this
view,
what
I
want
to
go
ahead
and
do
is-
I
want
to
let's
say
group
by
epic,
okay-
and
I
see
here-
let's
go
ahead
and
move
this
back
over
here.
A
Let's
say
we
tackle
that
one
or
release
one
and
what
this
lets
you
sort
of
do
is
see
all
of
your
issues,
grouped
by
the
feature
that
they
belong
to,
so
that
you
can
begin
to
sequence
them
out
into
upcoming
releases
and
so
given.
I
know
that
this
is
an
eight
week
period.
I
think
my
team
can
probably
get
50
weight
done
in
that
period.
There's
only
15
issues,
so
I'm
not
too
worried
about
that,
which
is
great
so
now
that
we've
done
this
basic
gist
of
doing
high
level
release
planning.
A
You
might
want
to
ask
like
how
do
I
actually
track
the
progress
of
all
this
stuff
at
a
high
level
without
having
to
dig
into
a
board
view,
and
this
is
sort
of
where
our
road
map
comes
into
play
and
our
roadmap
is
a
high
level
sort
of
executive
view
that
will
show
you
all
of
the
upcoming
issues
and
epics
that
you
have
scheduled
out
over
the
upcoming
releases.
So
once
an
issue
has
a
time
box
associated
to
a
milestone
or
due
date.
A
So
this
is
sort
of
a
great
view
to
get
a
high
level
understanding
where
things
are
going
to
go.
But
what's
interesting
is
if
we
go
back
to
our
board
now,
where
we
do
it
our
release,
planning
and
let's
say
that
we
know
something
is
going
to
take
it's
not
going
to
get
done
until
release
three,
for
example
right.
If
we
go
back
to
our
roadmap
because
of
that
kind
of
inherited
date
range,
we
automatically
see
that
the
epic
duration
has
been
adjusted
to
account
for
where
the
issues
have
been
scheduled
within
it.
A
A
A
So
if
we
look
at
the
detail
view
for
this,
we
can
see
right
now.
It's
linked
to
another
issue,
that's
actually
in
a
different
team
and
it's
blocked
by
that
team
completing
things
so,
within
the
board
view,
we
can
kind
of
see
that
this
implement
new
settings.
Endpoint
is
blocked
by
the
post
settings
issue.
The
post
settings
issue
is
right
here
and
because
of
that,
I've
gone
ahead
and
intentionally
sequence
out
these
other
issues
that
are
dependent
on
this
one
into
the
follow-on
iteration.
A
A
A
I
can
kind
of
see
the
status
of
where
they're
at
I
can
see
if
they're
blocked,
I
can
see
the
weights,
and
so
this
gives
me
a
great
view
like
if
we,
if
we
want
to
limit
the
number
of
issues
that
any
team
member
has,
we
can
also
set
work
in
progress
limits
on
an
issue
and
let's
say
that
I'm
only
supposed
to
be
working
on
two.
At
the
same
time,
we
can
go
ahead
and
do
that
and
you'll
notice
that
it
automatically
flags.
A
This
is
red,
and
so
this
is
a
great
way
to
see
and
manage
a
team
member
overload,
and
so,
if,
if
somebody
is
pulling
in
too
many
things,
there's
no
way
they're
going
to
be
able
to
work
on
four
at
a
time.
So
it's
a
great
signal
for
the
team
member
themselves
that
they
might
have
too
many
issues
assigned
to
themselves.
A
The
last
board
that
I
have
at
this
level
is
the
build
track,
and
this
is
where
this
board
has
been
scoped
to
the
current
iteration
and
what
that
means
is
only
going
to
show
issues
that
are
in
the
is
the
iteration
that's
currently
active.
This
is
what
the
board,
what
the
team
is
going
to
look
at
most
frequently
I,
as
a
product
manager,
I'm
probably
going
to
look
at
the
iteration
planning
and
the
release
playing
boards,
and
maybe
even
keyboards,
but
the
team.
They
just
want
to
know
what
they
need
to
work
on
next.
A
So
this
is
the
board
that
they
can
come
to
and
then
you
we
typically
pull
from
the
top
of
the
list,
and
so
if
this
let's
say
we
want
to
do
the
post
first,
because
we
know
that
that's
blocking
some
other
issues.
An
engineer
can
pick
that
up
moving
in
progress
and
then,
as
they're
working
on
things,
they
can
kind
of
move
it
through
the
different
cycles.
You
can
either
update
by
dragging
and
dropping
or
if
I'm
on
the
issue
detail,
view
itself
and
it's
ready
to
move
into
review.
A
Then,
when
I
go
back
to
my
board,
I
refresh
it
you'll
see
that
it's
now
in
the
review
state,
so
no
matter
where
you
edit
the
issue,
it's
going
to
be
reflected
on
the
board
itself,
because
this
is
sort
of
just
a
view,
a
way
to
kind
of
slice
and
dice
your
issues.
It's
super
helpful.
You
can
also
group
by
epic
within
this
field,
one
of
the
kind
of
cool
things
about
the
way
this
works.
A
Is
I've
created
a
lot
of
these
things
in
this
top
level
awesome
code,
but
if
you
want,
let's
say
your
team
to
have
their
own
views
into
only
their
own
things
and
I
go
into
this
consumer
products
group.
I
can
also,
from
this
view,
go
to
view
my
epics
review,
my
roadmap
and
I
see
just
those
road
map
items
which
are
within
the
consumer
products
group
itself.
A
So
I
don't
see
the
noise
of
everyone
else.
I
can
just
see
my
work,
and
so
this
is
where
it's
great
for
a
product
owner
to
be
able
to
view
things
at
this
level,
maybe
a
product
manager
at
the
higher
level,
but
you
have
these
sort
of
different
ways
and
different
options
for
how
you
roll
your
work
up
depending
on
where
you
create
it
at
this
level.
A
You
can
also
create
issue
boards,
just
like
you
did
at
the
higher
level
group,
and
so
if
we
want
to
go
ahead
and
create
a
let's
say,
iteration
board,
we
can
do
that.
We
can
pick
the
current
the
current
iteration,
that's
going
on
right
now,
which
I
think
is
seven
create
that
board
and
we
can
see
a
list
of
all
the
issues
within
this
specific
squad.
That's
responsible
for
delivering
these
specific
issues.
It's
pretty
handy
now,
let's
dive
into
the
issue
detail
view
a
little
bit.
A
The
issue
detail
is
similar
to
the
epic
detail.
It
just
has
a
little
bit
more
bells
and
whistles
to
it,
because
it's
where
most
of
the
work
actually
takes
place
within
the
issue.
You
can
add
a
time
estimate
if
you
want
by
a
quick
action.
So
let's
say
we
think
this
is
going
to
take
more
than
40
hours.
Let's
go
ahead
and
update
that
as
you'll
see,
this
is
updated,
the
estimate
to
eight
hours
and
then,
as
I
work
on
this
issue,
I
can
go
ahead
and
spin.
A
A
The
other
really.
Nice
thing
about
this
is
you
can
link
issues,
and
this
is
where
you
can
manage
your
dependencies.
We
also
have
something
called
the
design
manager
and
you
can
upload
designs
directly
from
your
desktop
and
what
this
does.
It
actually
creates
a
version
for
each
design
if
it's
a
if
it's
an
image
file,
and
if
I
upload
this
another
image
after
I've
updated
this
design,
it
will
actually
create
a
second
version
of
this
directly.
A
Here
we
have
a
figma
plug-in
which
lets
you
push
directly
to
issues
from
within
figma,
so
that
designers
don't
even
have
to
come
into
gitlab
in
order
to
push
their
designs
up
to
collaborate,
and
we
have
the
ability
within
when
we're
viewing
a
design
to
drop
pins
and
comments
on
different
things.
We
could
say:
hey,
gabe
weaver.
A
Do
you
think
this
should
look
the
same
as
the
create
button?
I
don't,
and
what
this
does
is,
when
you
add
mention
people
and
comments,
it's
going
to
create
a
to-do
for
them.
To-Do's
are
a
great
way
to
collaborate
with
team
members
in
gitlab.
As
you
can
see,
I
mentioned
myself
in
this
conversation.
I
can
go
to
my
to-do
list
and
it
says
right
here.
This
is
the
comment
that
was
added.
I
can
drop
directly
from
my
to-do
list
back
into
that
design.
I
can
interact
with
the
other
individual
in
this
case.
A
So
it's
a
great
way
to
integrate
and
collaborate
on
designs
between
engineering,
product
and
ui
ux
early
on
the
process
before
you
actually
get
to
implementation
similar
to
epics.
You
have
your
audit
history,
which
is
pretty
awesome,
and
you
also
have
the
ability
to
have
credit
conversations
just
like
within
epics.
A
A
So
now
I
can
see
the
total
account
or
upward
down
votes
and
that
those
issues
that
are
upvoted
the
most,
which
is
pretty
handy
you
can
also
within
the
list
view,
do
manual
mode
or
you
can
do
a
milestone
due
date
or
by
weight,
or
you
can
actually
filter
by
the
number
of
blocking
issues.
So
in
this
case
I
can
see
right
here
that
this
create
account
form
is
actually
blocking
two
other
issues
from
moving
forward.
A
A
A
What
a
lot
of
organizations
do
is
they'll
manually
test
that
they'll
have
a
test
case,
that's
sort
of
like
an
issue.
The
market
is
satisfied
after
somebody
goes
in
and
tests
that
out,
but
one
of
the
things
that
we
have
in
gitlab
is
the
ability
to
automate
this
at
the
basically
the
completion
of
requirements
or
marking
them
satisfied
or
failed
directly
by
linking
them
to
unit
tests.
So
if
I
want
to
create
a
new
requirement,
let's
say
make
the
button
green.
A
Or
let's
say
requirement:
the
button
should
be
green.
All
right.
You
have
the
ability
to
do
some
rich
text,
editing
in
here
as
well
for
tasks
if
you
want
to
kind
of
add
some
additional
color
in
context
to
how
the
requirement
should
behave.
But
as
you
can
see
right
here
now,
I
have
this
button
should
be
green
and
it's
not
marked
as
satisfied,
which
means
it
hasn't
been
started.
It's
not
in
the
progress.
It's
not
satisfied.
It
hasn't
worked
on
at
all.
A
A
What
this
will
do
is
create
a
merge
request.
It
will
start
a
branch,
as
you
can
see
it
automatically
copies
some
of
the
metadata
over
in
terms
of
milestones,
and
if
I
go
back
to
look
at
the
issue
itself,
you'll
notice,
it
automatically
relates
the
merge
requests.
So
the
actual
work
that's
going
to
be
delivering
this
issue
to
the
issue.
So
it's
really
helpful
way
to
kind
of
automate
the
flow
from,
if
you
think
about
all
the
way,
from
design
to
planning
to
down
to
your
merge
request
level.
A
So,
let's
say
within
this:
we
want
to
go
ahead
and
make
that
change
and
satisfy
that
requirement.
We
can
go
and
open
the
web
id,
which
is
our
browser-based
code
editor
and
I'm
gonna
go
into
my
actual
project
and
I'm
gonna
for
the
sake
of
this
demo.
I'm
just
gonna
go
ahead
and
copy
and
paste
this
and
let's
say
I'm
gonna,
add
a
new
file.
A
A
A
While
we're
waiting
for
that
to
run
how
about
we
hop
back
over
and
we
can
look
at
the
merger
questions
a
little
bit
similar
to
issues
in
epics
and
all
the
other
things
you
think,
gitlab
merge
requests
are
another
place
where
you
can
collaborate.
Similarly,
to
what
we've
talked
about
previously,
you
can
have
threaded
conversations.
You
can
see
your
pipelines
that
are
running.
A
You
can
see
the
relationships,
the
issue
above
it.
So
this
is
where
a
lot
of
engineers
spend
the
bulk
of
their
time
in
terms
of
once
they
actually
start
the
work,
but
the
kind
of
nice
thing
about
it
is
now
that
this
pipeline's
running.
If
I
were
to
go,
look
at
this
issue,
for
example,
I
can
actually
see
that
a
pipeline
is
running,
which
means
an
engineer's
picked.
It
up,
they've
actually
committed
some
code
against
this.
It's
in
its
draft
form,
it's
open,
and
so
within
the
issue
view
is,
if
I'm
a
product
manager.
A
We
can
go
look
at
our
actual
test
output
here
and,
let's
see
what
failed
so
right
here,
the
button
should
be
green.
The
status
is
that
so
because
this
test
failed,
then
this
test
is
linked
to
requirement
three.
If
I
go
look
at
my
requirements
list
now,
you'll
see
that
that
test
this
requirement
is
actually
failed
right.
So
this
is
a
great
way
that
you
can
dynamically
and
automatically
link
your
requirements
directly
to
the
test
cases
in
your
pipeline
and
in
the
code,
which
is
a
pretty
cool
thing
to
do.
So.
A
If
I
were
to
go
back
now
and
open
that
up,
let's
say
we
need
to
go
fix.
What
we
did.
We
can
open
up
the
web
id
right
again,
troubleshoot
it.
We
can
go
back
to
the
file,
that's
failing
and
we
can
make
the
changes
and
so
we'll
go
back
to
making
sure
that
the
test
can
pass
in
this
case
and
now
I'm
going
to
go
ahead
and
commit
this
change.
A
And
we
commit
that
up
and
that
that
does
that
automatically
triggers
the
pipeline's
front
again
and
what
will
happen
as
soon
as
that
gets
done
running?
It
will
mark
the
requirement
satisfied,
and
this
is
a
great
way
to
actually
tie
requirements
and
planning
objects.
Long-Lived
system
behaviors
that
you
want
to
document
directly
to
the
code
that
implements
them
so
stepping
back
a
minute.
Let's
go
up
and
talk
about
a
couple.
Other
neat
features
in
gitlab.
A
One
of
them
is
issue
templates
and
in
opps
I've
created
a
couple.
Different
templates
within
our
kind
of
settings
or
shared
repo
and
templates
are
just
markdown
files
that
live
in
a
repo,
and
here
I've
created
a
template
for
bug
and
I'm
going
to
go
ahead
and
use
the
quick
actions
that
we
have
within
gitlab
to
automatically
apply
a
bug
label
or
a
triage
label.
A
Whenever
this
bug
template
is
used-
and
let's
say
I
want
to
standardize
all
of
my
groups
of
projects
to
use
the
say,
the
same
set
of
templates,
and
I
want
to
essentially
manage
it
from
just
this
one
project
I
can
go
into
my
settings
within
my
top
level
group.
I
can
go
down
into
my
templates
and
I've
already
selected
that
project,
but
what
that
does
is.
A
If
I
want
to
go
back-
and
let's
say
I
need
to
create
a
bug
issue
and
the
api
project,
for
example,
I
can
go
into
this
project,
I
can
create
a
new
issue,
I
can
select
the
template,
say
bug
and
we
can
say
it
should
work
and
it
doesn't
work
and
it
doesn't.
I
can
enter
the
steps
to
reproduce
based
on
the
template
that
we
have
defined
and
then,
when
I
go
ahead
and
create
this
api
bug,
you
add
a
title,
create
the
issue.
A
A
A
One
of
the
things
that
I
want
to
talk
about
is
insights
and
insights
are
kind
of
interesting
in
that
you
can
create
your
own
customizable
dashboards
to
report
on
issue
of
merge,
request,
behavior
so
kind
of
in
this
ops
project
that
we
talked
about.
I
created
this
insights.yaml
file
and
let's
say
I
want
to
have
one
dashboard
page
in
my
in
my
company
insights
for
the
overview
I'm
going
to
have.
A
Basically,
I
want
to
see
all
the
open
by
type
work
items
I
want
to
see
that
per
week
and
so
I've
created
you
know
my
my
lower
level
work
items,
task
story,
maintenance
bug.
I
want
to
look
at
all
of
them
that
are
the
issues
that
have
been
opened,
I'm
going
to
group
it
by
week.
I
also
want
to
look
at
all
the
issues
that
have
been
closed
by
type
right,
and
so
it's
the
same
type
of
thing,
but
instead
I'm
looking
at
the
issue
we'll
state
it
closed.
A
So
now
I've
created
this
ops.
I
can
go
into
awesomeco,
I
can
go
into
my
settings
and
then
I
can
pick
this
that
ops
project
to
be
the
repo
or
the
kind
of
report
template
that
I
want
to
apply
to
this
to
this
group.
So
if
I
go
look
at
my
insights
report
now
I
see
that
dashboard
and
I
can
see
awesome
code
work
item
by
typed.
I
can
see
where
comes
closed
by
week
by
type
and
I
haven't
closed
anything
yet.
A
A
The
other
sort
of
report
that
I
use
a
lot-
and
I
think
I
find
it's
not
very
valuable-
is
our
value
stream
report
and
this
can
be
customized.
We
talked
about
our
two
sort
of
parallel
workflows
or
work
tracks
that
we
go
through.
We
have
the
build
track
and
we
have
the
refine
track.
What
you're
able
to
do
in
the
value
stream
report
area
is,
you
can
actually
create
custom
value
stream
reports,
so
here
I've
set
this
up,
I'm
naming
it
the
refine
track
called
the
first
stage
triage.
A
It's
going
to
start
counting
the
time
for
when
the
the
triage
label
is
applied
to
an
issue
to
when
the
triage
label
is
removed,
we're
also
going
to
measure
the
time
from
when
design
labels
applied
to
removed,
and
so
this
basically
mirrors
what
looks
like
our
refinement
process
or
our
climate
track
and
over
time.
As
I
work
on
my
different
issues,
it's
going
to
start
counting
the
time
and
state
for
each
of
those
issues
that
goes
that
flows
through
this,
and
I
can
measure
the
overall
lead
time
and
cycle
time.
A
I've
also
created
a
custom
report
for
the
build
track
which
mirrors
in
the
same
way,
so
there's
not
a
lot
of
data
here,
because
this
is
a
demo.
But
if
I
hop
over
to
gitlab's
actual
value
streaming
analytics
report,
I've
created
a
similar
one
because
we
have
a
workflow
as
well,
where
we
go
through
planning
breakdown,
solution,
validation,
design,
similar
to
what
I
showed
you
and
I
could
actually
look
across
all
my
different
stages
in
my
and
my
process
and
I
can
find
which
one
is
the
bottleneck.
A
So
our
build
track
starts
and
ready
for
development,
and
we
can
see
right
here
that
right
now
review.
If
I
look
for
this
down,
usually
if
it's
a
pull
based
system,
you
want
to
look
at
furthest
down
the
chain
to
see
what
the
longest
process
is
and
right
now
for
gitlab
that's
review.
I
can
click
into
this
review
stage.
I
can
see
the
total
time
and
stage
for
these
issues
that
have
gone
through
the
stage
as
immediately.
A
I
noticed
right
here
that
there's
an
outlier
there's
one
issue
that
was
in
review
for
212
days,
so
I
can
immediately
hop
in.
I
can
have
a
conversation
on
this
issue.
I
can
start
asking
questions
I
can
see
who
the
owners
for
this
were
and
try
to
gauge
what
what
do
we
need
to
do
to
fix
our
process,
so
things
don't
sit
there
that
long
right
it
could
have
been
just
you
know,
issue
hygiene.
It
could
have
been.
A
You
know
something
was
blocking
it,
but
what's
great
about
this,
is
you
get
the
snapshot
high
level
overview
of
all
your
work
items
that
have
gone
through
this
stage
and
you
can
see
which
ones
are
your
outliers?
You
can
see
which
what
your
median
time
is
in
stage,
and
so
it's
a
great
way
to
get
this
sort
of
overview
of
your
entire
process
and
also
be
able
to
understand
where
your
bottlenecks
are.
We
also
measure
our
lead
time
and
our
cycle
time.
A
So
this
is
an
absolutely
wonderful
report
and
that,
in
of
itself,
is
a
high
level
summary
of
how
you
could
do
multi-team
planning
within
gitlab
ultimate.
If
you
have
any
questions,
please
reach
out,
you
can
find
me
on
gitlab
at
g
weaver
and
feel
free
to
email
me
as
well.
My
email
is
on
some
of
our
direction
pages,
which
I
will
drop
in
the
notes
for
this
video
thanks
a
lot
for
spending
some
time
with
me.
I
hope
it
was
helpful
until
next
time.