►
From YouTube: Manage:Analytics Weekly 2020-06-23
Description
The Analytics group briefly walks the board, discusses 13.3 planning and a new approach to estimating issues for the upcoming release.
A
So
welcome
everybody
to
the
June
23rd
2020,
analytics
weekly.
We
have
a
couple
of
my
eyes
on
the
board.
One
of
them
is
about
a
pulse
survey
that
we're
doing
which
I
think
most
of
you
have
probably
seen.
If
you
haven't,
please
check
your
email.
So
first,
first
thing
here
is
the
walkthrough
of
the
board
so
share
my
screen
here.
A
B
C
A
D
D
A
E
Actually,
I
just
got
on
the
call
been
having
a
bit
of
audio
problems
in
my
child
single
series,
so
I've
been
working
above
the
controller
and
roots
just
to
start
on
the
skeleton
application
and
I'm
going
to
look
at
adding
the
chart
under
their
watch.
If
there's
anything,
really
important
updates
on
I
mean
we're.
Gonna
need
a
back-end
API
in
order
to
retrieve
data
on
the
front
end.
So
we're
just
going
to
be
adding
the
single
charge
of
the
single
cheerio
series.
E
A
E
E
A
F
So,
if
you're
interested
you
can
dive
into
that
I'm,
currently
extending
a
breakdown
that
Martin
put
together
that
highlighted
the
general
workflow
of
it
and
going
into
a
little
bit
more
detail
and
I'm
gonna
be
creating
tickets
for
this
I
just
haven't
gone
about
it
yet
because
I
kind
of
want
to
get
the
full
picture
before
creating
them,
but
I
expect
to
have
them
done
before
I
leave
today.
So
that
should
give
you
hopefully
some
more
detail.
I
might
also
add
a
few
more
questions,
clarifying
questions
on
there.
F
F
B
A
F
I,
don't
know
why
it
doesn't
show
up
I,
probably
am
missing,
to
add
a
label
on
to
it.
Perhaps
I
thought
I
had
added
the
right
labels
to
it,
I
already
implemented
and
there's
an
outstanding
mr
for
that
subtext.
That's
it
it's
something!
That's
going
to
require
a
little
bit
of
review,
because
it's
a
general
tart
chart
loader.
It's
not
really
like
a
huge
thing.
The
functionality
is
in
there,
but
we
want
to
before
we
close
this
issue.
F
We
want
to
make
sure
that
the
design
is
followed
completely
and
this
sub
tickets
is
kind
of
blocking
that
that
that
general
chart
loader
is
blocking
that
so
until
that's
myrrh,
which
I
cannot
put
up
the
EMR
to
actually
use
that
that
charge
loader
but
I
already
have
the
implementation
of
using
that
chart.
Loader
and
it's
a
really
small
MRR,
so
I
expect
that
to
go
pretty
quickly
as
soon
as
the
the
blocking
ticket
MMR
is
merged.
A
I
think
maybe
if
there's,
if
that
other
mr
was
executed
under
a
separate
issue,
that
issue
probably
just
doesn't
have
a
priority
label
on
it.
Right
now,
which
is
I,
don't
think
that's
a
big
deal,
I
mean
you're.
You've
got
it
under
way,
gotcha
John
Mason.
Was
there
other
you,
you
were
saying
you
hadn't
necessarily
applied
priority
labels
to
all
the
issues
in
13.
Was
there
more
you
wanted
to
cover
that
we're
not
seeing
here.
D
C
A
A
G
G
A
A
D
So
the
first
part
of
that
idea
is
to
make
a
specific
plan
about
which
items
were
going
to
estimate
on
a
weekly
basis,
just
so
that
we
make
sure
we
we
get
through
enough
of
them
and
we're
not
planning
sort
of
all
at
the
last
minute
and
then
have
a
really
quick
pass
that
says
hey.
This
is
not
ready
for
estimation.
The
proposal
isn't
clear,
you
know
john
mason
you've
got
work
to
do
and
then,
if
you
know
once
we've
got
a
clear
proposal,
focus
the
conversation
initially
on.
D
What
do
we
need
to
know
in
order
to
know
how
big
this
is?
You
know
from
my
perspective
and
estimation:
isn't
it's
not
a
commitment?
It's
just
a
best-guess
that
helps
us
know
whether
things
are
gonna
fit
into
our
release
or
not,
and
the
sooner
we
have
an
idea
about
that,
the
easier
it
is
for
me
to
begin
communicating
to
others
and
to
make
plans
about
other
stories
and
so
on,
and
then
I
think
that
the
conversation
can
then
transition
to
all
those
deep
dive
topics,
whereas
today
kind
of
what
I,
what
I
see
happening.
D
Is
that
we'll
we'll
pick
up
a
thread
of
one
topic
and
we'll
go
very
deep
on
that
topic?
And
eventually
we
come
back
for
up
for
air
and
we
discover
something
else,
and
then
we
go
deep
on
that
topic
and
so
on.
But
if
we
just
kept
the
conversation,
the
first
part
of
the
conversation
just
really
focused
on
well
how
big
this
is.
D
So
that's
that's
the
gist
of
this
proposal
here
and
I
have
started
a
13-3
planning
issue
that
sort
of
reflects
this
approach,
but
I
really
am
interested
in
your
opinion
as
to
as
to
what
you
think
about
this,
so
13-3
I
know
we're
just
starting
13-2.
It
seems
crazy
to
be
thinking
about
thirteen
three,
but
actually
you
know,
according
to
the
dates
we're
supposed
to
have
final
planning
done,
July
9,
which
is
really
just
a
few
weeks
away.
D
D
You
know,
for
example,
this
one
about
multiple
series,
simple
problem,
a
few
bullet
points
on
the
proposal,
a
picture
and
so
on
so
and
then
what
we
could
do
is
just
slot
those
issues,
take
a
quick
pass
and
say:
okay,
well,
which
ones
do
we
want
to
try
to
get
estimated
this
week
and
then,
which
ones
the
week
after
and
so
on?
We
can
the
ones
that
we
think
hey
this
might
take
longer.
There
may
be
a
lot
of
conversation.
D
D
A
So
John
Mason
justice
is
this
the
ideas.
Basically,
you
ask
engineers
to
come
in
to
specific
issues
and
give
a
rough
estimate
of
the
weight
just
based
on
the
initial
proposal,
and
then
you
know
schedule
it
into
a
milestone,
apply
the
workflow
scheduling
label
and
that's
kind
of
what
tells
us
okay,
this
needs
to
finish
refinement.
You
know,
engineering
needs
to
finish
refinement,
you
know,
apply
the
final
weight
estimate
and
then
it
moves
into
ready
for
development.
That's
that's
my
understanding
of
that
right.
A
H
So
my
question
is
just
for
my
own
edification,
the
the
problem
that
we're
trying
to
solve
here
is
coming
up
with
some
process,
where
we're
continually
doing
estimation
on
a
week-to-week
basis,
instead
of
kind
of
this
large
sprint
when
we
get
into
the
our
planning
process
for
the
next
milestone
every
month.
Is
that,
in
summary,
what
we're
trying
to
achieve
here,
yeah.
D
That's
a
big
part
of
it
for
me,
you
know
when
we
get
towards
the
end
of
our
release,
everybody's
busy,
trying
to
finish
up
mr
s
for
that
release.
It
puts
a
lot
of
pressure
to
have
everything
ready
for
kickoff
and
so
on
if
we're
kind
of
scrambling
last-minute,
but
if
we
can
plan
on
a
rolling
basis
and
I
think
it'll
take
a
lot
of
pressure
off
that
sort
of
final
weeks
of
planning.
C
Like
about
this
approach
is
that
it
could
help
us
in
the
long
run,
with
doing
a
better
planning,
especially
if
we
take
the
amount
of
weight
into
account
that
we
managed
to
deliver
in
previous
milestones.
So
if
we
would
have
like
a
couple
of
items
already
estimated
with
like
a
base
or
an
initial
number,
then
this
could
definitely
help
us
in
doing
the
next
milestones
were
planning
in
terms
of
when,
when
we
take
capacity
into
account
and
the
number
of
quality
that
the
sum
of
weight
that
we
delivered
in
the
previous
milestones.
H
H
Don't
I,
don't
know,
see
individuals
assigned
here
so
I
guess
that
we
would
be
just
trusting
either
EMS
or
individuals
to
just
kind
of
take
a
look
at
this
list
and
then
kind
of
take
that
estimation
work
on
also
this
this
list
here
that
we
see
isn't
attached
to
like
actual
status
of
the
issue.
So
someone
goes
and
estimates
half
of
the
lists,
half
the
list,
then
someone
else
comes
along
and
then
it
takes
look
and
they're
like
oh,
so
it
was
already
estimated
these
things.
H
So
you
know
my
only
quite
again
I'd
be
interested
in
the
engineering
departments.
Thoughts
here,
but
you
know,
maybe
we
can
just
do
like
a
Kanban
approach.
Here
we
have
like
a
list
elite.
Do
a
label
like
use
the
we
use
the
estimation
needed
label
for
a
while
and
then
relied
on
individuals
to
refine
and
then
pull
those
into
either
ready
for
development,
or
you
know,
workflow
breakdown
if
or
information
is
kind
of
needed
for
product.
A
A
You
know
just
in
terms
of
we
start
a
milestone
and
then
realize.
Oh,
we
need
to
finish
for
finding
this
thing
and
that
eats
up.
You
know
another
five
days,
which
is
basically,
you
know
the
first
week
of
the
milestone
and
then
things
slip.
So
just
for
context
here
for
those
who
haven't
been
on
the
analytics
team,
you
know
for
for
its
full
lifetime.
You
know,
since
starting
last
year
we
had
kind
of
an
issue.
You
know
we
basically
ran
into
this
issue
of
things
slipping
because
they
weren't
refined
kind
of
in
the
beginning.
A
So
we
shifted
our
process
to
invest
more
in
refinement
upfront
to
like
have
a
more
solid
estimate
upfront
before
we
started
execution.
You
know
before
we
even
committed
to
anything
in
the
milestone.
So
that's
that's
why
the
process
is
the
way
it
is
right.
Now
I
definitely
see
how
that
can
be
a
little
bit
rigid,
sometimes
so
it
seems
like.
Maybe
this
is
about
you
know,
shifting
back
and
having
a
little
bit
more
of
a
middle
ground.
You
know
I,
my
thinking
is
it's
an
experiment.
A
Let's
try
it
out,
you
know,
I
see
how
planning
has
been
complicated
by
not
having
estimates
sort
of
early
enough.
So
you
know
the
the
rough
estimate
and
then
finish,
refinement
and
do
a
final
estimate.
As
long
as
we
still
try
to
finish
the
refinement
before
the
milestone
starts.
I
think
that
can
work.
B
C
D
You
know
weeks
and
people
for
each
of
of
them
and
so
people
sort
of
know
which
ones
they're
responsible
for,
and
we
could
do
that
on
a
week
to
week
basis
or
we
could
do
it
all
up
front,
but
that
I
think
would
create
a
lot
of
clarity
and
to
the
point
about
issue
labels
and
keeping
track
of
things.
I
did
go
through
and
I
cleaned
up
all
of
the
next
up
labels,
so
the
next
up
labels
ought
to
match.
D
That
has
the
filters
next
up
and
analytics
and
so
on,
which
might
might
help
us
as
well.
We
don't
have
to
use
this
board.
We
could
do
it
some
other
way,
but
I
I
haven't
been
using
issue
labels.
You
know
very
carefully
and
I
recognized
that
that
could
be
a
pain
for
other
people,
so
I'm
trying
to
be
more
clear
about
things
and
in
the
issue,
labels.
F
F
Li
lack
of
better
word,
leaning
up
against
a
lean
mythology
and
I
think
that
I've
tried
to
do
something
like
that
before
and
I
think
that
works
really
well
yeah.
There
does
seem
to
be
like
some
concern,
at
least
for
me,
also
on
getting
like
having
to
monitor
a
page
or
something
to
to
go
back
and
remind
myself
that
I
need
to
do
estimates
there's
a
bunch
of
different
ways.
We
could
solve
this,
but
I
could
see
that
as
a
bit
pitfall.
F
Perhaps
like
weekly
noted,
like
a
message
like
we
do
with
I,
can
remember
the
weekly
reports.
Engineering
reports.
I
can't
remember
the
exact
name
of
that,
but
but
do
something
similar
to
like
a
reminder,
go
go
and
do
some
estimates
that
could
be
an
initial
pass,
but
I
could
see
it
be
a
pitfall
that
that
we
would
forget
otherwise
something.
G
To
stuff
and
like
kind
of
fiddling
around
on
me,
if
I
cannot
do
something
because
I
don't
have
your
context
and
maybe
I
can
pass
it
on,
and
trade
with
somebody
else,
I
think
for
me
personally.
It
would
be
easier
to
can
have
it
in
my
list
of
issues
that
I
have
to
work
on
and
then
I
can
remember
better.
D
I'm,
just
taking
a
look
at
the
agenda
here
to
see
how
much
more
time
we
have
for
this
conversation,
because
I
think
it
would
be
really
cool.
If
well
do
do
you
do
we
want
to
take
a
crack
at
doing
some
initial
sort
of
assignment
of
these
things
right
now
on
the
call,
or
do
we
want
to
do
that
after
the
call
I.
D
D
Next
week
we
have
Tuesday
June
30th.
We
have
our
regular
weekly
meeting
and
then
pre-planning
is
already
on
July
2nd,
which
is
just
that
same
week
on
Thursday
and
then
final
planning
on
on
Thursday.
So
the
planning
comes
up
a
lot
faster,
I'm,
always
surprised
by
how
fast
it
comes
up,
and
hopefully
we
can
get
a
little
bit
ahead
of
it,
and
so
so
I
would
recommend
if
we're
gonna
do
this,
that
we
we
try
to
to
pick
some
issues
tomorrow
for
our
first
week.
So.
A
John
Mason:
do
you
want
to
like
maybe
just
follow
our
practice
of
paying
us
in
the
planning
issue?
You
know,
maybe
you
can
ping
the
whole
group
or
you
can
just
think
Martin
and
I,
and
and
we
can
figure
it
out
whenever
you
have
added
more
items
to
one
of
these
estimation
sections
do
you
do
you
want
to
just
do
it
that
way,
or
did
you
have
another
way
in
mind?
Oh.
D
D
A
D
I
G
G
C
A
So
Martin,
you
just
reminded
me
of
something
else
here.
If,
if
we
assign
an
engineer
on
one
of
these
things,
it
may
not
have
been
split
into
implementation
issues
yet
I'm
wondering.
Would
we
want
the
initial
assignee
to
come
in
for
the
rough
estimate
and
go
ahead
and
break
it
out
and
estimate
each
of
those?
Or
do
we
just
want
to
do
like
an
extremely
rough
high-level
estimate
on
the
parent
issue?.
C
My
my
gut
feeling
tells
me
giving
a
rough
rough
estimate
on
something
that
requires
both
back
and
front
and
some
time
it's
really
hard
for
a
front-end
engineer,
to
give
it
even
a
rough
estimate
on
the
backend,
because
we
don't
really
know
what
implication
is
or
if
it's
got
to
be
like
it
performance,
everything
or
so
I'd.
Rather
have
it
the
parent
issue
being
split
up
into
separate
issues
and
then
have
the
dedicated
engineer
own.
We
estimate
the
relevant
portion.
F
Extending
what
Magdala
has
said
a
little
bit
earlier,
I
think
it
would
make
sense
just
like
again
assign
somebody
and
then,
if
they
feel
like
they
need
somebody
else's
second
opinion.
They
can
co,
assign
them
and
then
do
an
estimate
together
or
like
split
it
up
into
two
tickets
if
they
feel
like
that's
necessary,
but
just
to
make
it
as
easy
as
possible.
Maybe
just
assigning
one
person
and
then
mm
just
pull
in
the
people
that's
necessary
from
there
and
let
that
person
be
the
driver.
Essentially.
A
And
actually
I
think
this
probably
falls
on
engineering
managers
shoulders.
When
you
know
when
we
try
to
assign
you
know
anything
that
isn't
self
assigned
by
somebody
will
come
in
make
sure
it
gets
an
assignee
and
probably
at
that
time,
try
to
split
it
out
into
the
implementation
issues
and
yeah.
Okay,.
F
I
I
No
point
in
in
representing
all
that
much
stuff.
However,
I
will
point
you
towards
the
the
message.
I
left,
NRG
manage
analytics
slack
channel
and
if
you
can
provide
feedback
on
on
the
little
post,
that
I
put
in
our
slack
channel
I
think
that
should
suffice.
It's
a
little
prototype
still.
Let
me
know,
let
me
know
what
you
think
of
it
and
click
on
the
issues
that
I
posted
there
and
they're
pretty
self-explanatory
and
take
a
look,
but
that's
it
I'll
pass
it
over
Martin.
C
Yeah
only
have
a
small
like
an
FYI
I'm,
just
sharing
what
the
manage
input
group
has
implemented,
so
they
they
launched
a
first
experiment.
I'll
link
the
the
guidelines
in
our
agenda
duct,
and
that's
probably
something
that
we
should
keep
an
eye
on
in
in
the
future.
If
we,
if
we
ever
want
to
implement
some
sort
of
ap
a
be
testing
for
some
of
our
analytics
features.