►
From YouTube: Stack ranking issues using the RICE framework
Description
A quick overview how the Memory team can utilize the RICE framework to stack rank issues quickly. This can help provide clarity and help align on priorities.
It is also fun!
See https://about.gitlab.com/handbook/product/product-processes/#using-the-rice-framework
Memory issue: https://gitlab.com/gitlab-org/memory-team/team-tasks/-/issues/72
A
Hello
memory
team:
this
is
a
quick
video
to
talk
you
through
our
prioritization
exercise
using
the
rice
framework,
which
is
a
really
quick
way
to
understand
how
different
issues
rank
in
priority
and
decide
what
to
do
first,
so
the
replacement
for
much
more
granular
and
also
very
important
sort
of
problem
validation
efforts.
This
is
really
a
way
to
take
a
list
of
of
issues
or
epics
and
understand
where
you
should
start
so,
given
that
we
have
exactly
that,
I
prepared
a
little
example
for
you.
Let
me
quickly
share
my
screen.
A
Okay,
so
you
did
the
a
week
where
you
focused
on
understanding
how
we
can
reduce
gitlab's
memory
footprint,
ideally
bring
it
under
two
gigabytes
of
memory
and
as
an
output
from
that
there
is
actually
a
large
list
of
potential
features
or
improvements
enhancements
to
gitlab.
That
would
allow
us
accomplish
this
goal,
but
what's
unclear
at
the
moment
is
really
where
to
start,
and
what
I
proposed
in
the
meeting
yesterday
is
to
use
rice
it's
linked
here,
but
just
going
into
the
handbook
how
to
use
it.
A
It's
essentially
a
tool
to
stack
rank
issues
to
figure
out
quickly
if
certain
parts
or
certain
certain
features
have
a
higher
priority
than
others
in
it.
As
you
can
see,
it
talks
about
reach,
so
how
many
customers
will
actually
benefit
in
our
case,
for
example,
is
something
only
available
to
a
small
number
of
self-managed
customers.
This
is
relevant
to
github.com
and
then
scaling
in
that
regard.
The
impact
is
about
if
the
changes
that
we're
going
to
make
are
going
to
impact
our
our
users
and
how
they
will
actually
impact
them.
A
In
our
specific
case,
we
can
use
memory
consumption
as
a
proxy,
so,
for
example,
if
a
specific
change
would
reduce
the
memory
consumption
by
500
megabytes,
that's
obviously
a
massive
impact
if
it's
only
minimal
like
a
couple
of
kilobytes,
maybe
a
lot
lower,
but
also
really
think
through
the
user
impact.
Here,
it's
like
memory
consumption
is
important,
but
what
does
that
actually
mean
to
our
users?
Do
we
have
to
disable
something
that
otherwise
would
just
work?
That's
not
particularly
desirable
right.
So
keep
that
in
mind.
A
Confidence
is
just
to
scale
for
our
understanding
of
a
problem
so,
for
example,
the
dropping
the
gitlab
exporter
there
is
already
a
notion
of.
We
are
not
quite
sure
exactly
what
requires
the
exporter,
how
it
will
impact
users,
so
there's
more
research,
so
that
reduces
our
confidence
at
the
moment
and
then.
Lastly,
it's
about
effort.
A
A
It's
going
to
take
six
months,
really
huge
effort,
and
you
want
to
normalize
by
that,
and
all
of
these
scores
can
then
be
used
to
calculate
the
rise
factor
or
rise
score
for
an
an
issue,
and
so
I've
laid
this
out
down
here
for
you
in
a
little
example
for
the
gitlab
exporter.
So
this
is
my
understanding.
The
exercise
for
you
is
to
do
it
for
yourself
and
then
we
can
come
together
later
in
the
week
and
actually
discuss
that
synchronously,
but
this
can
be
done
async.
A
So
for
the
gitlab
exporter
I'm
estimating
the
reach
is
pretty
high.
You
know
this
is
something
that
also
impacts
gitlab.com.
It
will
probably
impact
most
of
our
self-hosted
customers,
so
high
reach
impact,
100
mb
memory
reduction
sounds
relatively
high
to
me,
so
I
gave
it
a
two
70
confidence.
Some
things
are
unknown,
but
overall
it
sounds
like
we
have
some
understanding
of
it
and
optimistically,
I'm
going
to
say
it's
taking
going
to
take
two
months.
Who
knows
maybe
longer
so
I
calculate
the
right
score.
560.
A
and
that's
for
one
feature
in
here.
There
are
more
so
the
individual
score
is
not
as
important
right
if
it's
540
or
520
right-
that's,
at
least
in
my
opinion,
not
really
where
the
meat
is.
The
interesting
thing
will
be,
if
gitlab
exporter,
in
comparison
to,
for
example,
extending
the
ruby
vm
with
frozen
string,
literal
deduplication,
which
has
a
score
of
100,
but
that
gives
us
an
indication
that
maybe
addressing
the
gitlab
exporter
first
is
a
higher
priority
compared
to
that.
So
it's
the
relative
ranking
of
those
items.
A
It
obviously
becomes
smaller
if
you
have
tiny
differences
because
they
are
essentially
random
and
depend
more
on
our
understanding,
so
give
it
a
try.
It's
important
to
do
this
quickly,
don't
spend
too
much
time
on
it.
This
is
a
quick
way
of
getting
prioritizations
and
clarity.
This
is
not
a
you
know,
spend
half
an
hour
on
each
issue.
Do
it
as
fast
as
you
can,
and
then
we
can
come
back
collaborate
and
discuss
goodbye.