►
From YouTube: View epic relationships in epic
Description
Discussing the design in https://gitlab.com/gitlab-org/gitlab-ee/issues/7327 and the future
A
A
B
C
B
A
Yeah,
so,
okay,
so
we
can
see
in
the
sidebar.
So
let
me
see
if
I
can
open
an
epic
that
has
that
okay.
So
let
me
share
my
screen,
maybe
it's
better
example,
this
epic,
you
can
see
here
in
the
sidebar
that
we
have
two
ancestors
and
what
you're
saying
is
that
if,
if
we
have
another
epic
inside
of
this
epic
I
would
then
see
be
able
to
see
three
no.
B
A
C
Between
but
not
to
see
the
ancestors
right
and
I
think
I
think
that's
why
you
try
to
to
clarify
at
least
or
that's
my
understanding.
This
design
was
not
focused
to
see
your
ancestors
is
only
like
one
linear.
You
can
see,
because
by
definition
of
how
we
define
this,
you
can
only
ever
have
one
parent.
So
if
you're
going
upwards,
you
can
only
see
one
only
the
parent
of
the
parent
of
the
parent,
but
if
you're
going
downward,
you
can
see
the
splayed
out
tree
yeah.
D
A
A
You
would
likely
do
the
same
here
in
this
tree,
so
you
could
reorder
the
issues
inside
of
your
descendants,
not
your
ascendance,
but
only
your
descendants
and
I
think
this
it
when
you're
using
something
like
the
from
milestone
so
you're,
inheriting
the
planning
that
you're
doing
in
the
issues
and
you're
then
dragging
and
dropping
those
issues
between
epochs
I.
Think
you
fail
to
see
the
big
picture
of
all
of
this
right,
and
this
is
where
the
the
road
map
comes
in,
and
my
initial
proposal
was
to
explore.
A
It
allows
you
to
see
the
events
that
are
coming
before
and
after,
but
at
the
same
time,
when
you're
planning
to
find
a
time
somewhere
in
someone's
calendar,
you
can
see
the
whole
basically
the
whole
calendar
of
those
people
as
well.
So
what
I'm
saying
is
that,
having
the
only
the
descendants
tree
here
and
then
having
the
roadmap
separately
to
that,
and
then
you
can
see
the
whole
roadmap
in
another
place
and
the
whole
tree
of
the
other
app
is
in
another
place.
I
think
it's
a
bit.
A
It's
like
planning
in
in
a
vacuum
right,
yeah,
I,
think
you're.
Only
seeing
this
in
a
very
narrow
way,
but
then
again
this
is
my
assumption
and
ultimately,
what
I'd
like
is
for
us
to
do
some
research
on
this
instead
of
committing
to
something
as
complex
as
having
this
roadmap
or
can
I
ask
a
question
sure
that
that's
what
we're
here
for.
A
Okay,
so
yeah
from
a
technical
point
of
view.
Probably
yes,
that's,
that
would
be
the
ideal
yeah
and
what
I'm
saying
is
that
if
you
do
this
here,
you
don't
have
that
visibility
of
what
this
is
potentially
affecting.
Yeah
I
see
you,
don't
you
don't
know,
because
this
is
you
here,
it's
it's
a
very
detailed
view,
but
you
lose
the
big
picture
and
this
is
again.
This
is
my
assumption
and
also
looking
at
what,
for
example,
JIRA
as
with
their
other.
C
A
C
C
Research
as
well
NER,
but
but
the
way
I've
seen
it
is
that
they're
not
mutually
exclusive
design-wise
right
I
think
you
would
agree
right
like
I
agree,
there's
there's,
obviously
some
mutually
exclusive
like
what
do
we
build?
First
right?
Should
we
or
should
we
iterate
on
the
thing
that
like
should
we
do
iterate
on
tree
and
then
of
the
roadmap
and
then
tree
and
the
roadmap
and
tree
and
roadmap,
so
that
that's
one
approach
or
the
other
approach
is
just
treat
your
shoes
your
tree
and
then
come
back
to
roadmap
and
I?
C
Think
I
was
always
I
think
up
to
now,
we've
been
sort
of
doing
the
latter,
maybe
subconsciously
where
we've
been
really
just
talking
a
lot
about
the
tree
and
really
hadn't
really
been
focused
on
the
road
map,
so
I
think
that's
definitely
a
blind
spot.
So
so,
at
least
from
a
design
perspective
we
should
be
aware,
but
maybe
not
necessarily
from
me.
What
do
we
build
next
perspective
and
then
so?
C
Some
teams-
just
don't
do
that
like
you'll,
that
we
don't
really
do
that
right.
If
you
think
about
it
right,
we
just
say
we're
gonna
ship,
something,
and
we
don't.
We
just
move
it
to
the
next
milestone,
so
that
we're
not
really
good
at
predictability.
And
then
we
even
say
that
in
our
handbook,
so
my
as
in
my
in
the
customers,
I've
talked
to
in
general
for
plan
and
for
a
manager
in
particular,
more
people
are
really
caring
about
right.
C
Now
the
the
work
breakdown
structure
and
they
really
love
the
fact
that
there's
multiple
levels
but
they're
annoyed
that
they
can't
number
one
add
a
child
right
away
and
then
so
we're
addressing
already
and
number
two
being
able
to
flexibly
move
things
around
because
they
want
to
do
that
so
you're
totally
right.
If
they
do
that
that
will
affect
timelines
but
I'm.
C
That's
also
great
and
now
look
at
that
after,
but
they're
not
concerned
about
that
when
they're
moving
things
around
that
the
fact
that
you
know
issue
a
belongs
to
epic
B
and
this
your
C
belongs
to
epic
D.
That's
not
about
planning
in
the
time,
but
it's
about
logically
or
semantically.
I
split
my
work
in
this
way
across
these
teams
and
therefore
I
want
to
move
things
around.
So
that's
why
I've
been
comfortable
with
just
focusing
on
the
treeview
in
particular
treaty
that
doesn't
have
a
roadmap
in
particular.
Now.
F
F
You
wanna
see
like
the
boundaries
when
it
is
started
and
when
it
is
planned
to
be
ending
and
stuff
like
that.
So
when
you're
looking
very,
very
deep
and
dirty,
it
adds
a
lot
of
complexity
rather
than
looking
at
the
immediate
children
and
not
all
of
the
descendants
of
the
epic.
So
it
kind
of
makes
because,
like
each
child,
should
be
kind
of
embedded
within
it
within
its
parents.
F
Boundaries
timewise,
like
it's
kind
of
easier
to
plan
for
the
immediate
children
there
and
to
plan
for
the
and
to
see
all
of
the
descendants,
because
this
tree
can
can
get
pretty
big
if
you
were
showing
all
of
the
children,
the
epics
and
then
all
of
the
issues
and
everything
and
out
in
that
roadmap.
So
maybe
it
makes
sense
but
like
as
if
first
iteration
or
something
it
does
to
me.
F
E
Agree
in
terms
of
complexity,
I
think
it's
easier
and
one
thing
that
I
would
like
to
know
related.
The
relationship
of
the
tree
and
the
road
map
is.
Is
it
correct
to
say
that
the
road
map
consumes
data
from
the
tree
to
be
built?
I
mean
like
I.
Imagine
that
when
creating
an
epoch,
I
would
create
a
new
date
and
things
like
that
and
start
date.
Yeah.
Is
it
correct,
then,
that
the
road
map
will
be
based
on
this
data
and
it's
like
static
or
dynamically?
C
That's
correct,
Walmart
and
Alexandria
I
want
to
I
want
to
be
careful
to
focus
this
discussion
more
on
the
design
and
the
use
cases,
and
let's
come
back
to
those
technical
considerations
once
we
have
the
design
we
all
agree
on
and
so
that
we're
not
like
they
are
relevant
but
like.
Let's
not
limit
our
innovation
on
that.
Let's
limit
our
MVC
on
that.
Definitely
right,
but
not
not
the
amazing
ideas.
Hey.
G
Can
I
ask
a
question
just
kind
of
step
back
a
little
bit?
Are
we
all
on
the
same
page
that
tree
view
should
be
dealt
and
we're
just
trying
to
determine
if
it
makes
more
sense
to
build
it
inside
of
issues
or
epics
or
if
it
makes
sense
having
its
own
standalone
app
or
if
it
makes
sense
having
it
built
alongside
roadmaps
right
now,
I
think.
C
I
think
we
agree
on
all
those
if
those
are
end
or
statements,
I
would
well
I
mean
that
means
you
can
agree
to
anything,
but
I
want
them
in
all
those
places
like
well
I
mean
I.
Think
it
makes
sense
that
to
your
initial
question,
does
this
preview
make
sense?
I?
Think?
Yes,
it's
like
the
best
view.
That's
why
we
have
like
finder
on
Mac
and
Windows
Explorer,
whatever
it's
called
on
Windows
it's
a
great
paradigm.
We
should
use
it
so.
B
Coming
back
to
what
Pedro
said,
one
of
the
things
that
the
thing
that
I'm
least
convinced
by
it
is
what
he
touched
on
earlier,
where
you
see
your
descendants
and
I
think
it
is
I
agree,
it's
completely
a
valuable
thing
to
see.
Just
like
we
have
the
widgets
right
now
we
have
the
epics
and
of
the
issues.
This
is
just
combining
them
into
one
view.
I
think
it'll
be
great
to
see
how
they
relate
to
each
other.
B
What
I
don't
like
is
what
he
said
when
you
move
something
you're,
seeing
only
it
in
a
descendent
view
and
you're
not
seeing
what's
happening
above
that.
So
I
was
talking
to
another
designer
Andy
a
couple
weeks
ago
and
we're
trying
to
think
of
a
way
to
see
everything
like
you've
got
your
ancestors
on
the
sidebar,
but
which
is
I,
think
is
also
useful.
Just
it
gives
you
sort
of
a
North
Star
like
this
is
where
I
am,
and
this
is
now
I
can
orient
myself.
A
I
think
I
think
that's
that's
better!
I
think
that
that
helps
a
little
bit
to
to
place
yourself
for
me
that
wasn't
the
main
concern
I
mean
that
helps
yes,
I.
What
I
was
saying
is
that
I
mean
this
is
again.
This
is
all
about
sizing,
something.
But
let's
imagine
that
you
want
to
actually
move
one
issue
from
this
epoch
into
a
completely
different
epoch,
and
in
that
case,
what
you
were
just
saying.
Maybe
if
only
you
see
the
entire
tree,
you
would
be
able
to
move
them.
A
That
makes
sense,
but
also
in
terms
of
time
and
coming
back
to
what
Victor
was
saying
earlier.
There's
I
think
there's
two
parts
to
this
right.
There's
the
part
about
you
starting
a
project
breaking
down
into
the
different
work
pieces,
and
so
you
start
creating
one
epoch
and
then
a
sub
epoch
and
then
issues
inside
of
this
about
epoch.
A
And
then
you
realize,
oh,
we
need
another
epic
here
for
another
and
you
start
writing
all
of
that
down
and
we
that's
a
way
that
a
lot
of
teams
work
and
we
need
a
really
good
interface
that
allows
you
to
create
issues
and
epics
effortlessly
and
not
the
way
that
we
have
today
where
you
have
to
go
through
different
forms
and
then
in
create
when
it's
and
you
always
have
to
create
things
and
then
link
them
instead
of
creating
in.
But
that's
that's
a
different
thing.
A
A
A
What
I'm,
what
I'm
saying
is
that
if
we
try
to
have
the
work
breakdown
structure,
for
example
here
in
this
tab
bar
inside
of
the
issue
in
the
episode
of
the
epoch,
probably
in
the
future,
we
will
have
the
same
kind
of
tree
near
the
road
map.
So
you
can
see
what
you're
affecting
when
you're
changing
the
work
breakdown
structure
and
how
that
is
affecting
your
planning
in
time
and
so
I
think,
ultimately,
probably
will
be
duplicating
efforts
and,
okay,
you
can
say
okay,
but
we
can.
A
We
can
start
in
this
direction
and
we
start
by
having
these
two
tabs,
for
example,
and
then,
when
we
join
everything
in
a
roadmap,
we
deprecate
these
instead
of
having
to
maintain
two
separate
views
of
the
same
thing.
But
what
I'm
arguing
is
that
maybe
we
should
study
the
problem
more
closely
and
I
drew.
Could.
A
A
When
you
change,
when
you
move
one
of
these
issues
somewhere
else
to
another
epic
or
maybe
when
once
we
have
this
inheritance
of
dates,
probably
even
bubbling
up
to
the
ancestors,
when
you
change
something,
you
can
immediately
see
that
if
the
dates
will
change
you,
maybe
you
don't
have
visibility.
Yeah.
You.
C
D
C
Around
because
you
see
all
the
metadata
and
you
see
the
description,
you
see
any
potential
comments,
and
so
on
and
so
forth.
So
I
wouldn't
I,
wouldn't
rely
on
the
road
map
view
alone.
To
have
people
do
management
of
objects
is
what
I'm
saying
yeah
I
think
in
line
management
here
makes
a
lot
of
sense
as
well,
as
does
the
road
map
YouTube.
A
Yeah
I
think
it
does
I'm
just
not
sure
if,
if
it's
worth
solving
here
first
instead
of
of
the
roadmap,
we
definitely
need
to
have
here
some
kind
of
work,
breakdown,
structure,
I'm
just
really
happy
to
have
it
here
and,
as
I
said,
you
end
up
affecting
some
things
that
you
just
don't
know
will
be
affected.
I.
C
Mean
if
you
have
it
in
the
in
the
roadmap
view
I
like
the,
but
my
original
point
is
that
people
are
already
using
this
view
to
create
their
work,
breakdown
structures
and,
if
you're
having
it
in
the
roadmap
view.
That's
great,
then
people
are
be
gonna,
be
driven
to
the
road
map
view
to
do
the
work
breakdown
structure.
We're
essentially
saying
that's
where
we're
gonna
do
that
right
and
that
to
me,
that's
a
little
bit
harder
to
do.
C
It's
gonna
take
a
little
bit
more
longer
to
iterate
to
get
there,
and
so,
if
you
do
it
that
way,
it's
I
think
to
achieve
that
goal.
It's
less
iterative,
I,
don't
I!
Don't
I'm,
not
saying
it's
a
big!
No,
because
it's
also
a
more
strategic
move
to
to
have
people
pay
more
attention
to
tide
lines
and
to
encourage
higher
adoption
of
that
particular
UI.
So
that's
a
that's
a
riskier
approach.
It.
B
C
C
I
would
say
it's
not
the
case
in
many
organizations
where
you
know
I
or
like
there's
tools
out
there,
where
you
just
drag
something
from
one
end
to
another
in
the
roadmap
view
to
create
something
because
I
want
this
thing
to
be
in
the
third
quarter
of
blob
right,
so
I
think
there's,
there's
usage
of
that
to
know
about
time,
but
for
hands,
but
I
would
agree
with
the
animal
that
that
what
I
wouldn't
want
to
do
that
and
I
think
that's
a
little
bit
more
risky.
As
as
the
next
step,
you.
A
B
It's
kind
of
what
I
already
said,
just
the
the
treeview
in
particular
I,
quite
like
the
tabs
and
I
like
having
the
discussion
the
tree
and
then
the
roadmap
of
the
epics
that
are
already
included
on
this
epic.
But
the
tree
in
particular
was
what
I
just
yeah
like
what
I
said
earlier.
You
can't
see
the
ancestor
so
you're
sort
of
dragging
and
dropping
things
and
doing
potentially
destructive
actions,
maybe
by
mistake-
and
you
don't
like
if
you
dropped
one
and
kind
of
in
a
random
place,
you
wouldn't
even
know
where
you
put
it.
B
You'd
have
to
go
and
search
through
and
look
at
the
system
notes
to
decide
so
I
liked
the
idea
of
creating
some
kind
of
view
where
you
see
the
entire
top
bottom
tree
and
only
being
able
to
drag
and
drop
in
that
view,
because
our
other
places
where
we
drag
like
issue
boards
and
related
or
you
know
the
epic
issues,
those
aren't
destructive.
Really
they
just
you,
drag
and.
C
Animal,
don't
you
think
it's
it's
similar
from
great
that
you
brought
up
the
shoe
bar,
because
I
think
it
is
analogous
when
I
think
of
issue
board,
there's
a
scope
on
the
issue
board,
so
there's
a
scoping
from
the
board
config,
but
there's
also
a
scoping
from
the
fact
that
it's
part
of
a
group
or
part
of
a
project.
So
when
I
look
in
an
epoch
tree
thing,
there's
also
a
scoping.
The
scoping
is
the
roots
because
you're
at
the
particular
epoch,
and
so
assuming
that
you
can
only
see
your
descendants.
C
The
scoping
to
me
is
the
fact
that
you
are
who
you
are
you're
the
root.
And
then
you
look
at
your
children,
and
so
you
can
move
your
children
around
and
to
me
that's
enough
context
that
I
don't
screw
up
enough,
and
so
you
mentioned
like.
Oh,
if
you
made
a
mistake,
we
can.
You
know
use
UI
tricks
to
do
that
like
when
you
move
something
around
it
doesn't
commit,
but
from
a
scoping
perspective,
I
think
that's
totally
fine,
because,
yes
I,
don't
know
my
ancestors
and
I,
don't
know
any
impact
that
we
have
there.
B
That's
kind
of
what
I
was
thinking
when
I
started
a
design,
but
even
on
the
one
that
that
page
I
think
the
middle
one.
You
can
see.
There's
a
blue
row
there
and
I
think
this
was
one
of
the
many
markups
that
I
made
that
it
was
sort
of
incomplete.
But
in
that
view,
that
blue
row
is
supposed
to
be
the
issue
that
you're
currently
on
or
the
epoch
you're.
Currently
on
so
I
think
this
view
is
showing
the
entire
tree
top
to
bottom
roots.
B
B
C
And
I'm,
not
against
your
design,
I'm
just
saying
yeah
like
if
you
think
that's
a
I,
think
that's
a
small
thing.
I
think
the
tree
view
is
great.
I.
Think
it's
really
hard
to
make
a
tree
view.
Look
good
like
so
I'm
struggling
with
that
because,
like
the
MA
codes
are
okay,
but
they
don't
look
awesome
but
I'm,
not
against
showing
your
parents,
and
so
I
would
maybe
say,
like
you,
don't
share
your
share
parents
by
default,
then
maybe
you
click
a
button
and
you
see
more
or
I.
Don't
know
like.
C
C
B
Current
mock-up
that
we're
looking
at
isn't
the
most
recent.
The
most
recent
is
below
that
and
in
the
issue
description.
But
this
was
going
to
be
more
like
a
collaboration
when
it's
yeah
it
was
going
to
look
more
like
that,
which
is
what
we
already
have
just.
These
are
kind
of
a
little
bit
less
tall
than
what
we
are
currently.
C
No
I'm
fine
with
proceeding
with
this
I
Pedro.
Do
you
think
this
is
okay?
Should
we
really
take
a
close
look
at
the
I
mean
if
designers
have
time,
I
mean
designed
this
and
row
map
you
at
the
same
time
and
then
and
then
do
more
of
the
research
and
so
on
and
so
forth,
but
I
personally,
don't
think
we
need
to
necessarily
slow
down
and
not
work
on
this
like
in
eleven
ten
or
eleven
eleven
or
whenever
we're
working
on
it
and
we
can
proceed,
but
that's
my
thought.
Pedro.
A
We
should
have
some,
even
if
it's
not
very
detailed,
we
have,
we
should
have
some
plan
or
idea
or
even
rough
sketch,
of
how
we
could
eventually
I
mean
right
now.
What-What
Annabel
has
suggested
here
and
we've
worked
on
is
probably
to
have
the
the
tree
and
the
road
map
inside
of
the
epic
right.
We've
also
agree
that,
maybe
in
the
future
we
might
have
a
tree
next
to
the
main
road
map.
Would
you
right
and
that's
that's
a
separate
thing.
A
In
how
should
I
say
it?
What's
the
term
in
a
more
cohesive,
cohesive
way
is
the
fact
that
we
have
in
the
middle
we
would
have
the
tree.
I
mean
it's
similar
to
what
you
were
saying.
We
have
the
tree
and
we
can
show
only
the
descendants.
We
can
show
the
descendants,
an
descendants
and
the
issues,
but
then
we
also
have
the
tree
here
in
the
sidebar
or
in
this
case
will
be
the
ascendance.
A
And
so,
if
you
want
to
navigate
to
the
descendants,
you
use
this,
but
any
if
you
want
to
go
to
the
ascendance.
You
use
this
part.
So
it's
a
completely
different
area
and
then,
at
the
same
time,
I
think
we
should
have
an
like
a
strong
opinion
on
what
we.
What
the
sorry,
let
me
the
open
is
that
what
the
main
epic
lists
is
for
right,
because
in
this
epic
list
there
is
no
tree,
it's
just
basically
a
flat
list
of
the
epics,
and
we
should
be.
A
You
have
to
go
inside
of
an
epic
and
then,
if
you're
inside
of
an
epic,
maybe
you
only
see
the
children
epics
and
issues,
but
not
the
ascendance.
Descendants
are
on
this
side.
So
what
I'm
trying
to
say
is
that
these
three
parts
that
to
me
look
a
bit
disjointed
and
I'd
like
to
see
some
even
rough
idea
of
maybe
how
this
can
look
in
the
future.
Even
if
we
start
first
with
this
tablet,
which
only
shows
the
children
does,
it
make
sense.
What
I'm
saying.
C
B
Don't
know
that
it
needs
to
be
I,
understand
what
you're
saying
I'm
trying
to
think
if
it,
if
it
I
like
the
ListView
a
little
bit,
especially
once
I
create
an
ethic
because
I
like
to
see
that
it
was
created
and
there
it
is
at
the
top
and
I.
Sometimes
I,
look
I
search
by
different
criteria
and
I
like
they're
all
at
the
same
level.
B
C
I
think
animal
within
with
Pedro
or
it
is
what
I'm
hear
from
you.
Pedro
is
just
how
how
these
designs
come
together
right
because
there
is
a
lot
of
duplication
and
use
cases.
So
I
agree
if
at
least
there's
two
use
cases
I
can
think
of
right,
just
creating
work
breakdown
structure,
because
you
have
an
idea
of
how
you
want
to
divide
up
work.
A
A
This
is
verbose,
or
this
is
too
conversational,
but
have
an
interface
that
allows
you
to
just
type
out
the
structure
as
you're
talking
with
your
team
or
with
your
client,
and
you
start
seeing
the
structure
building
up
here
instead
of
having
to
create
an
epic
go
inside
of
the
epic
and
then
create
the
structure
by
itself.
That's
that's,
probably
a
separate
thing.
What
I'm
a
bit
worried
is
that
we
don't
have
again.
It
doesn't
need
to
be
definitive
vision,
but
have
some
idea
of
how
we
can
bring
all
of
this
together.
A
This
list
view
the
the
sentence
with
with
the
tree
and
also
the
ascendance
here
on
the
sidebar.
This
to
me
feels
like
we
could
end
up
in
the
near
future
with
a
very
disjointed
experience,
which
is
fine.
This
I
mean
that's
that
skip
live
right.
We
we
ship
things
and,
in
certain
points
in
time,
things
feel
a
bit
disjointed,
but
then
it
feel
they
feel
good
again,
but
I'm
not
seeing
that
good.
Now,
right
and
even
if
it's
a
rough
sketch
I
feel
like
we
have
enough
information
to
be
able
to
have
that
vision.
Essentially.
B
A
E
A
No,
no,
not
at
all
I,
don't
think
I,
don't
think
it
blocks
us
from
developing
the
the
feature
I
mean
I.
Think
we
we
should
from
from
the
conversation
that
we're
having
I'm
more
certain
about
the
idea
that
it's
here
I
just
feel
like.
This
is
an
exercise
that
we
can
do
in
parallel
as
we
develop
this,
because
I
think
we
should
work
it
at
both
levels
right.
We
should
work
at
a
list
ik
level
in
a
very
rough
way.
A
Seeing
oh,
this
can
go
in
this
direction
right
at
the
same
time,
be
very
precise
and
detailed
on
what
the
next
step
is,
and
the
next
step
in
this
situation
is
to
view
the
epics
inside
of
an
epoch
right
now
we
we
can't.
We
have
this
area,
but
it's
just
the
children
and
the
direct
children.
You
don't
see
other
than
that,
and
then
you
have
the
ancestors
here
in
the
sidebar.
So
the
tree
view
makes
sense
to
have
the
in
the
epoch.
G
Have
we
have
we
discussed
other
way
or
is
there
a
use
case
for
a
child
that
needs
multiple
parents
so
say
in
the
okay?
Our
way
of
working
we've
got
an
okay
are
so
objectives
as
the
parent,
the
parent
parent
and
then
we've
got
he
results,
and
then
we
have
issues
tied
to
those
key
results.
But
if
those
issues
are
tied
into
multiple
objectives,
have
we
thought
about
that
at
all,
or
is
that
a
use
case
that
maybe
we
have
found
that
it's
not
an
actual
use
case?
G
C
Something
that
I
think
at
least
one
person
has
asked
for
me-
maybe
I
think
Chris
Jones
no
no
shows
for
something
else,
but
we
we
purposely
designed.
We
were
more
conservative
in
our
design
because
we
can
do.
We
can
go
in
one
direction
and
the
direction
that
we
can
go
is
to
be
more
broad
and
so
I,
so
pager,
animal
anyway
Japan
but
I.
C
If
we
intend
to
use
epic
to
represent
work
breakdown
structure,
then
scope
is
law
of
conservation
of
scope,
essentially
right,
because
if
you
have
multiple
parents,
then
where
you
put
your
scope
into
and
if
we
start
doing
things
like
adding
up
story
points
or
we
call
them
weights
it
give
up.
Then
things
get
really
weird
so
right
now.
This
is
the
current
design
I,
like
the
current
design.
I,
don't
see
a
compelling
case
to
loosen
dr.
straighten
yet
and
I
think
we
should
be
open
to
it
when,
when
the
time
comes,
yeah.
G
A
D
I
mean
I
kind
of
agree
with
both
you
Victor
said
something
about
like.
Oh,
if
you
want
to
see
the
whole
relationship,
you
can
just
go
to
another
epic
like
go
to
the
ancestor,
I,
guess
and
I'm
like
well.
Maybe
we
just
allow
people
to
do
that
more
easily,
like
I
think
that
was
the
Annabelle's
point
and
then
also
I
had
that
same
thought
like
okay,
why
can't
I
just
toggle
between
like
a
backlog
or
like
just
a
list
of
epics
and
then
also
see
the
whole
tree?
D
If
I
just
want
to
see
the
entire
relationship
that
makes
sense
to
me,
I'm
still
trying
to
figure
out
exactly
what
these
things
mean,
but
I
mean
as
someone
who
hasn't
used
this
before
really
it
is
I
agree
with
you
kind
of
confusing,
like
there's
all
these
like
list
views
and
like
different
views
that
are
trying
to
like
to
me
as
a
novice
user
I'm
like
well.
What
what
exactly
are
they
should
they
tell
me?
Is
it
competing
information?
C
D
A
We
understand
our
use
case
pretty
well,
that's
that's
us
at
github
and
yeah
I
think
maybe
some
some
research
with
with
customers
and
could
help
and
having
also
the
designers
in
direct
contact
with
with
customers
asking
those
questions
could
lead
to
open
up
to
more
I
mean,
what's
similar
to
what
Donald
woods
were
saying.
Oh
have
we
looked
at
all
possibilities
and
all
different
are
we
I
think
maybe
dhama?
What
you
were
saying
is
have.
Are
we
thinking
outside
of
the
box?
What
are
the
the
things
we
are
not
looking
at?
A
There
are
just
next
to
us,
and
maybe
that
could
help
uncover
exactly
what
you
were
just
saying.
For
example,
the
list
view
of
epics.
Do
people
want
to
immediately
start
worth
doing
the
break
work
breakdown
structure
from
that
screen
instead
of
having
to
create
an
epic
I
mean
this
is
just
me
assuming
I
mean
I
would
love
to
be
able
to
do
that.
But
that's
me
I,
don't
know
if
customers
and
other
users
would
love
to
and
that's
I
think
when
we
need
to
do
so.
A
A
So
yeah,
nonetheless
I
think
this
discussion
was
reported.
I
know
if
anyone
else
wants
to
bring
up
anything.
If,
if
so,
please
interrupt
me,
I
think
that
I
can
so
for
this.
These
ideas
that
I
was
talking
about
I
know
Victor.
Do
we
have
any
issues
for
this?
The
the
tree,
viewing
the
epic
lists
and
having
a
faster
way
to
detail
the
work
breakdown
structure,
no.
F
A
Whoo
yeah,
it
was
great
to
see
everyone
here
in
this
call
and
contributing
with
their
thoughts.
So
thank
you
so
much
Paul
Mir,
Alexandra,
I
access,
Donald
and
it
all
Victor
and
I'll
plug
this
to
get
live
and
sheltered.
Unless
anyone
once
isn't
like
that's
going
to
be
I.
Am
that
is
cool.
Thank
you.
So
much
I
was
great.