►
Description
How a GitLab Product Manager uses GitLab in product planning tasks - Breaking down an Initiative using GitLab epics and issues
A
I
want
to
walk
you
through
how
I
use
gitlab
features
in
my
planning
process
as
a
product
manager
and
specifically
for
this
video
I'm,
going
to
focus
on
decomposition
of
large
initiatives
or
features
using
using
gitlab
X.
Okay.
A
So
in
this
case
I'm
showing
you
an
initiative
that
we're
actively
working
on
which
is
work
items-
and
this
is
a
very
large
work
effort
that
spans
several
different
groups
here
at
gitlab,
and
you
can
see
just
how
large
this
work
effort
is
because
we
have
dozens
of
sub
epics
here
for
individual
feature
sets
and
when
we
expand
one
of
these,
you
can
see
how
we
have
broken
down
that
individual
feature
into
smaller
work
items
using
gitlab
issues
so
before
I
dive
into
how
this
is
broken
down.
A
I
want
to
kind
of
point
out
some
important
features
of
epics
that
you're
going
to
want
to
use
for
your
planning
processes
to
make
them
easier
in
the
future.
So
the
first
one
is
dates.
You
can
set
fixed
states
on
the
Epic.
If
you'd
like
or
you
can
allow
them
to
be
inherited
and
inherited,
will
simply
scan
all
of
the
issues
that
are
related
to
this
epic
and
set
the
start
date
as
the
very
first
start
date
of
the
issues
that
are
under
the
Epic
and
the
due
date
as
the
very
last
one.
A
So
if
I
were
to
add
another
issue
and
I
put
it
I,
don't
know
out
to
November
of
this
year,
this
will
update
to
November,
and
these
dates
are
important,
because
when
we
take
a
look
at
our
roadmap,
the
plotting
of
this
epic
and
then
in
sub
epics
will
be
based
on
the
Epic
start
and
due
dates.
The
next
thing,
that's
really
important.
A
Are
labels
you're
going
to
want
to
add
labels
to
your
epic
in
such
a
way
that
you
can
use
them
to
filter
so,
whether
you're
using
an
epic
list,
an
epic
board
or
an
epic
roadmap?
The
labels
will
allow
you
to
Target
the
information
you
want
and
get
rid
of
the
noise.
So
in
my
case,
I
like
to
apply
a
group
label
which
represents
my
group
to
our
epics
and
issues,
another
label.
A
That
would
be
helpful
that
I
am
currently
using
is
a
time-based
label,
so
I
can
take
a
look
at
maybe
everything
for
this
year
versus
everything
that
I
was
working
on
last
year
and
you
could
get
really
creative
with
labels
here,
so
you
can
customize
that
to
your
needs.
The
next
thing
is
the
Epic
color.
Once
you
get
to
road
maps,
The
Epic
color
will
allow
you
to
kind
of
distinguish
epics
by
visual
representations
through
color.
These
can
be,
it
can
represent.
A
Teams
it
could
rep
represent
initiatives
could
represent
goals,
whatever
makes
sense
for
your
organization
and
that's
basically
the
the
metadata
that
I
think
is
really
important
to
make
sure
that
you're
adding
to
all
of
your
epics.
So
as
I
mentioned,
this
is
a
really
large
initiative.
That's
across
all
groups,
so
I'm
actually
going
to
take
the
group
label
off
because
it's
more
than
just
my
group
and
I'm
going
to
apply
something:
that's
a
higher
Step
Above
group
here
at
gitlab
and
that's
devops
plan.
A
So
that
applies
to
both
my
group
and
my
sibling
groups
within
plan.
Okay
and
now,
let's
take
a
look,
we
we
see
that
the
initiative
is
work
items
and,
let's
take
a
look
at
an
individual
feature
within
this
work
items
initiative
and
that
is
subscribe
to
Notifications.
So,
just
like
we
see
here
on
this
epic
there's
a
little
toggle
to
subscribe
to
Notifications.
We
have
this
throughout
gitlab.
A
So
take
this
with
a
grain
of
salt
but
I
like
to
create
a
design
issue,
a
back
end
issue
and
a
front-end
issue
you
for
all
of
my
work
and
if,
for
some
reason
it
doesn't
need
one
of
those,
then
I
omit
it.
For
example,
if
it
was
API,
work,
I
wouldn't
need
design
and
and
front
end,
but
typically
our
features
require
all
three.
A
So
what
this
allows
me
to
do
by
having
these
three
separate
issues
is
it
allows
me
to
stagger
the
assignment
of
time
of
when
I
hope
to
get
this
thing
scheduled
and
and
into
the
dev
cycle,
so
with
design,
for
example,
here
this
was
scheduled
for
the
last
Milestone
15-9
I
have
the
back
end
scheduled
or
actually
whip
in
the
current
Milestone,
and
then
the
front
end
in
the
next
Milestone,
and
this
is
because
we
don't
want
to
work
these
things
in
parallel.
A
Right
back
end
should
be
aware
of
what
the
designs
are
for
this
feature,
to
make
sure
that
their
back
end
can
accommodate
that
and
also
the
front
end.
The
other
nice
thing
about
creating
three
separate
issues
for
this
work
is
it
allows
me
to
block
the
front
end,
for
example,
so
if
I
open
up
my
front
end
record
I
can
see
that
this
work
front.
End.
Work
item
is
blocked
by
the
design,
which
is
now
closed,
so
it
would
technically
not
be
blocked.
A
If
that
was
the
only
thing
that
was
here,
but
it
is
still
blocked
because
it's
blocked
by
back
end
now,
sometimes
we
can
get
started
on
front
end
and
stub,
something
out
just
wait
for
back
end
to
ship,
but
I
like
to
stagger
so
that
we
can
start
something
when
it's
completely
shovel
ready.
So
once
this
back
end
shifts,
then
this
will
be
unblocked
and
you'll
notice
that
I
like
to
use
workflow
labels
to
also
designate
that,
and
then
we
can
get
started.
A
So
this
is
a
very
simple
example
of
how
I,
like
to
decompose
features,
starting
from
large
initiatives
to
a
smaller
feature
set
and
the
tools
that
we
need
to
make
sure
that
we
can
pull
on
these
efforts
in
different
views
like
list
Sports
and
road
maps.
Take
a
look
at
future
videos
where
I
will
show
you
those
next
steps
thanks
so
much.