►
From YouTube: Product Planning: Epic Start & Due Dates
Description
How a GitLab Product Manager uses GitLab in product planning tasks - how epic dates work, what's the difference between "inherited" and "fixed", and which do I use?
Here's the issue I referenced in the video: https://gitlab.com/gitlab-org/gitlab/-/issues/231511
A
Hey
everybody,
I'm
Amanda,
Rutha
I'm,
the
senior
product
manager
with
product
planning
here
at
gitlab,
and
today,
I
want
to
walk
you
through
how
I
use
start
and
start
and
due
dates
on
epics
I'm,
also
going
to
share
some
background
about
how
it
works
and
why
you
might
use
one
over
the
other.
So
let's
talk
about
the
dates
specifically
inherited
dates
set
on
an
epic
will
inherit
the
earliest
start
date
and
the
latest
due
date
from
its
child
records
and
children.
Records
of
an
epic
can
be
both
epics
and
issues.
A
The
information
that
it's
pulling
from
an
epic
is
the
actual
start,
and
due
date
of
that
sub,
epic
and
those
sub
epics
could
be
using
fixed
or
inherited
for
purposes
of
passing
that
date
up
to
the
parent
for
child
issues.
There's
a
number
of
different
kind
of
date.
Related
data
points
on
the
issue,
but
the
only
one
that's
observed
for
inherited
inherited
dates
on
an
epic
parent
is
the
Milestone
start
and
end
date.
A
A
A
It's
only
the
Milestone,
not
iteration,
not
due
date,
and
if
you
want
to
see
what
the
start
and
end
is
of
a
milestone,
you
can
click
on
it
and
you
can
get
into
the
Milestone
page,
which
will
show
you
the
start
and
end
dates
in
two
different
places
here.
So
you
might
be
asking
you
know
why
would
I
use
inherited
versus
fixed
and
I
went
too
fast
there?
A
Okay,
so
epic
dates
are
really
important
to
me
as
a
product
manager
and
I
use
them
a
lot,
because,
more
than
anything,
they
help
me
plan
my
near
term
like
what
am
I
doing
this
Milestone
next
to
next,
and
also,
in
some
cases,
longer
term
road
maps.
When
I'm
thinking
about
you
know
the
next
three
quarters
or
a
full
year,
I
want
to
kind
of
play
with
the
puzzle
pieces
that
are
my
large
initiatives
on
the
roadmap
and
decide
which
is
going
to
come
first.
A
But
you
know
a
lot
of
times.
I
get
the
question
what
which
of
those
epic
dates
should
I
use,
so
I
think
about
this
in
the
stages
of
planning
or
the
product
Dev
workflow.
So
if
you're
still
in
the
really
high
level
planning
stage,
you're,
not
breaking
down
that
feature
or
initiative
anytime,
soon,
you're,
just
thinking
about
like
what
am
I
going
to
do
for
the
next
six
months
or
a
year,
you're
looking
at
a
longer
Horizon
use
fixed
States.
A
Why,
by
using
fixed
States
at
this
point,
you're
going
to
be
able
to
use
the
roadmap?
If
you
don't
have
any
dates
on
your
epics
and
you
navigate
to
the
roadmap,
it's
going
to
be
blank
because
a
roadmap
is
displayed
by
dates
and
for
better
or
worse.
If
you
don't
have
any
dates
on
your
FX,
then
the
roadmap
is
going
to
be
it's
non-useful
for
you.
A
As
long
as
people
are
adding
a
milestone
to
your
issues
and
all
of
your
sub
epics
are
set
to
inherited,
and
your
roadmap
will
provide
you
with
a
higher
confidence
of
the
estimate
of
when
this
project
is
going
to
deliver
at
that
point,
I
should
mention
that
you
can
have
a
mix
and
match
so
you
could
have
like
the
ultimate
parent
epic
be
inherited,
but
like
a
sub
epic
be
fixed
because
it's
not
being
broken
down
yet,
but
a
different
sub-epic
being
inherited.
A
So
there's
no
problem
with
mixing
and
matching
types
of
dates
just
know
that
whenever
you've
set
something
to
fixed,
it's
going
to
expect
you
to
update
it
the
system's
not
going
to
take
over
for
you
when
things
get
broken
down.
A
A
I
want
to
reiterate
that
the
roadmap
works
with
both
fixed
and
inherited
so
again,
depending
upon
where
you
are
this
particular
project
I'm
showing
you
is
like
deep
in
the
weeds
of
a
project
that's
been
going
on
for
a
while,
so
we're
definitely
using
inherited
for
this
one.
A
All
right,
I
just
want
to
highlight
where
we're
going
kind
of
what's
the
road
map
for
dates
with
epics
in
the
future
and
so
beyond,
expanding
them
to
pick
up
data
for
for
iterations,
for
example.
We
also
want
to
expand
the
feature
to
allow
for
using
fixed
as
planned
dates
and
inherited
as
actual
dates
so
that
you
could
use
both
of
them
together
right.
A
You
could
actually
set
a
fixed
State
as
the
plan
that
you're
making
like
let's
say,
you're
doing
that
long-term
planning
and
then,
as
the
work
gets
broken
down,
it
automatically
inherits
the
actual
dates,
and
what
this
will
allow
you
to
do
is
view
the
difference
right.
You
can
see
quickly
at
this
point.
How
far
ahead
of
schedule
are
we
or
how
far
behind?
Are
we
or
doing
a
look
back
some
things
delivered,
but
what
was
that
Delta
implant
versus
delivery?
A
So
if
you
want
to
learn
more
about
this
issue,
please
do
react
with
a
thumbs
up,
because
that
tells
us
that
there's
interest
comment.
If
you
want
to
add
any
of
your
use
cases,
and
if
it's
you
know
something
you'd
like
to
see
toggle
on
the
notifications
to
get
updates
on
it.
So
it's
issue
get
lab
issue,
two
three
one,
five,
five!
A
Thank
you
so
much
for
your
time
and
if
you
have
any
questions,
feel
free
to
hit
me
up
on
any
issue.
You
can
find
me
at
Amanda,
ruida,
on
gitlab
and
I.
Look
forward
to
chatting
with
you.