►
Description
Requirements Management Office Hours held on 03-April-2020
B
B
Anyway,
this
this
proposal
is
just
more
technical,
detailed
set
of
steps
which
we
might
use,
and
there
is
one
change
in
the
compared
to
original
proposal.
Instead
of
parsing
the
wall
output
of
specs,
which
might
be
a
little
bit
hard
and
challenging,
there
is
a
suggestion
to
use
a
separate
CSV
file
which
might
be
much
easier
to
implement
and
perhaps
also
use
so
yeah.
A
I
love
this
and
I
think
it's
a
very
good
MVC
idea,
because
it
it
simplifies
things
a
bit
on
our
end,
and
it
would
be
something
that
we
could
always
iterate
into
you.
You
know
additional
parsing
later
if
we
needed
to,
but
it
starts
us
off
with
something
that's
a
little
bit
simpler
for
an
MVC
which
I
think
is
great
I
did
comment
on
it.
A
A
I
think
there's
one
issue
already
under
that
epoch,
which
is
basically
just
a
copy
of
the
epoch
down,
because
I
promoted
the
issue
to
an
epoch,
so
I
had
to
make
another
issue.
That's
basically
said
the
same
thing,
but
we
can
reuse
that
issue
for
whatever
we
want.
If
we
want
to
break
down
something
like
this
or
whatever
we
land
down
as
a
final
solution,
we
can
just
reuse
that
the
solution,
validation
issue
is
more
of
I.
Don't
think
we're
gonna
do
this
solution
validation!
A
This
quarter,
especially
with
Nick
the
designers
out,
he's
been
out
all
week.
It's
gonna
be
very
difficult
for
me
to
have
a
solution:
validation
without
it
I'm,
so
we're
probably
gonna
go
ahead
and
without
a
solution
validation.
So
we
can
reuse
that
issue
if
necessary,
but
no
I
think
this
is
excellent.
I
love!
A
It
thank
you
so
much
the
other
agenda
item.
I
added
was
we
are
working
hard
through
this
quarter
to
define
North
Star
metrics
is
sort
of
a
new
thing.
We're
trying
here.
I,
don't
think
it's
just
on
the
product
side,
but
I
think
this
is
sort
of
driven
by
the
product
side
we're
trying
to
define
North,
Star
metrics
for
all
of
our
areas,
so
for
us
to
certify,
as
a
group
is
doing
a
North,
Shore
metric
and
with
servicedesk
being
moved
down
to
core
and
quality
management
not
really
up
and
running.
A
A
So
again,
it's
it's
a
high
bar,
that's
well
known
by
Scott
and
Helia
hila,
who
are
sort
of
leading
this
effort
off,
but
I
guess
I
just
wanted
to
kind
of
socialize
that
and
get
feedback
I
mean.
How
does
that
seem
for
the
team
and
I
do
recognize.
This
will
change,
probably
in
q2,
because
the
idea
is
it's
going
to
be
something
that
the
team
will
be
looking
toward
longer
term.
These
are
like
one-year
kind
of
things
it's
just
since
we're
just
releasing
the
feature.
A
A
This
is
where
it's
hard
for
me
too,
because
I
said
we
need
to
put
something
in
place
for
q1.
Now
he
won
technically
ends
the
end
of
this
month,
which
is
about
a
week
after
release,
but
I
got
the
distinct
feeling
that
they
were
really
looking
for
when
key
one
ends.
Are
we
in
a
state
where
we
could
achieve
this?
Not
so
much
we
have
already
achieved
in.
A
Think
that's
a
much
more
difficult
put
than
getting
a
hundred
requirements
created
because
I
can
create
a
hundred
requirements
overnight.
If
I
really
had
to
not
that
that's
the
goal
of
this,
but
the
creation
of
the
requirements
is
not
the
difficult
part.
It's
the
getting.
The
Foundation's
laid
that
we
are
able
to
create
the
requirements.
B
Yeah,
okay,
well,
my
toll
is
that
it
will
be.
It
will
be
tight
to
get
requirements
out
of
door
in
12
to
10
I
think
we
are
finishing
qi
at
this
point.
So
if
we
manage
to
deploy
and
then
just
we
should
still
make
it
and
three
move
the
feature
flag
which
it's
still
behind
feature
flag.
The
thing
is
that
in
supposing
we
released
it,
it
will
be
just
about
having
list
of
requirements,
but
there
will
not
be
still
a
connection
to
tests.
B
A
Believe
so,
I
think
what
we're
trying
right
now
is
we're
hoping
that
people
in
the
sales
people
start
demoing
this
to
customers
and
saying:
hey,
look:
here's
how
you
create
requirements!
We
understand
that
we're
still
immature,
but
we
want
people
to
start
playing
with
it
and
provide
feedback
on
the
interface
and
I
thought
that
a
hundred
requirements
throughout
demos
and
people
playing
with
it
was
a
pretty
realistic
put
mainly-
and
this
is
what
Justin
and
Scott
and
Eric
have
all
sort
of
agreed
to
was.
The
purpose
of
this
is
more.
A
Can
we
get
the
features
out
the
door
pick
something
that's
hard,
but
not
impossible
and
I
think
getting
the
feature
out
the
door
in
twelve
ten
is
hard,
but
not
impossible.
So
I
think
that
lined
up
with
their
vision,
long
term.
What
we're
looking
to
do
is
not
so
much
measure
the
number
of
requirements
created,
because
most
programs
will
create
a
bunch
of
requirements
and
then
do
nothing
with
them
other
than
link
tests
to
them
and
reference
them
over
the
development
lifecycle.
A
So
a
long
term,
we
would
like
to
measure
interactions
with
requirements,
creating
a
link
viewing
the
requirements,
because
that
shows
that
people
are
then
referencing
those
requirements,
which
is
what
really
provides
the
value
of
requirements
management,
it's
not
being
able
to
create
requirements.
It's
being
able
to
have
a
single
source
of
truth
that
you
link
all
your
things
to
so
long-term.
A
The
vision
is
these
Nordstrom
metrics
will
be
about
increasing
the
interactions
with
requirements
as
a
way
to
measure
our
success
with
creating
a
viable,
lovable
or
viable,
then
mature
than
lovable
product
for
requirements
management
because
the
more
the
people
are
using
by
viewing
them
the
more
it's
been
ingrained
into
their
development
process
and
the
better
we're
doing
so.
I
think
that
makes
sense
long
term.
It's
the
short-term
one
that
I've
been
struggling
a
little
bit
more
fifth,
so
okay,
well
I'll,
leave
it
for
now.
A
C
Yeah,
just
on
that
like
if
there
is
a
risk
to
requirements
management
by
not
making
it
by
the
end
of
twelve
ten,
maybe
we
could
get
that
surfaced
a
week
in
advance
or
something
that
would
lies
to
take
contingency
measures.
Ie
deliver
something
like
concrete
requirements
through
graph
key.
Oh
maybe
we
could
patch
that
up
and
lift
the
feature
flag
there
and
then
at
least
we'd
be
able
to
list
requirements
and
create
them
via
graphical
like
so
that
we
can
deliver
something
like
yeah
I
knew
there
was
no
risk
there,
but
like
just
just
that.
C
A
Really
appreciate
that
I
think
that'd
be
great,
because
we
do
have
to
release
something
in
twelve
ten
I
think
that's
the
feeling
and
if
we
do
have
to
fall
back
in
a
minigame
plan,
we
have
to
fall
back
in
a
mitigation
plan.
That's
that's
how
this
goes,
but
no
I
think
the
earlier.
We
can
define
success
and
then
you
know
I
trust
that
John
and
Donald
can
kind
of
make
the
call
as
to
when
we
start
cutting
people
over
to
the
mitigation.
A
C
A
I
did
want
to
clarify
with
regards
to
the
documentation
that
I
know
Justin
poked
out
a
little
bit
yesterday
and
was
just
asking
you
know
we
need
to
get
something
there.
We
don't
have
to
make
perfect
documentation
for
this.
One
of
the
iteration
office
hours
I
watched
was
Sid
was
basically
him
saying
that
the
technical
writing
team.
He
thought
it
was
more
the
technical
rewriting
team-
and
he
said
basically
what
he
was
looking
for.
Engineering
to
do
was
simply
when
they
emerged.
Their
Docs
have
something
there.
The
technical
writing
can
work
with
so
I
think.
A
If
we
go
with
that
approach
and
I've
already
talked
to
Marcin
about
this
he's
on
board.
As
long
as
we
put
something
in
that's
just
a
basic
overview,
we
can
let
him
bulk
it
out
till
his
heart's
content
and
make
it
really
great,
but
it
could
be
as
simple
as
click
here
to
create
acquirement.
This
is
what
it
looks
like
click
here
to
see
this
done
like.
Let's
not
make
that
a
difficult
part
of
this.
Let's
try
to
make
that
as
as
easy
as
possible
for
us
just
to
get
something
in
the
box.
I'm.
A
Also
about
ready
to
write
an
issue
to
propose
that
we
try
something
a
little
bit
different
requirements,
management
and
Docs
as
well.
We
have
been
tasked
in
product
to
these
speedruns
every
month
for
new
features
where
it's
basically
a
30-second
to
two-minute
video,
where
we
just
quickly
demonstrate
these
features,
I'm
gonna,
post
an
issue
and
see
what
it
would
take
to
get
those
embedded
or
linked
to
from
the
docs
and
starting
with
requirements.
Management
makes
sense
because
we're
starting
at
the
ground
floor,
but
people
often
say
our
Docs
are
difficult
to
follow.
Sometimes
not
sure.
A
B
A
Yeah
cool
now
that
makes
great
sense.
I
didn't
really
know
how
to
do.
Videos
for
API
portion
I
was
gonna
mainly
do
videos
demonstrating
a
front-end
because
I
think
that's
where
most
fort
users
will
be,
but
again
I
was
hoping
to
make
it
so
that
also,
if
team
members
in
engineering
wanted
to
create
speedruns
as
well
like
if
they
found
some
neat
way
of
accomplishing
something,
I
want
to
make
this
open
to
everybody
where
we
can
just
do
a
quick
video
when
we
find
things
in
our
in
our
product.
That
are
you
know.
A
Oh
that's
a
neat
way
of
doing
that.
I
should
make
a
30-second
clip
on
it.
You
know
why
not.
It
gives
people
a
chance
to
contribute,
and
hopefully
it'll
help
our
users
in
an
organized
fashion,
because
the
complaint
right
now
is
people
have
complained
about
the
docks
and
that's
one
thing.
But
people
also
say
that
our
unfiltered
channel
is
so
difficult
to
find
things
on.
But
if
you
wanted
a
speedrun
for
something,
it's
it's
hard
to
find.
A
So
this
sort
of
links
them
together,
I
think
our
documentation
is
searchable
right
now,
which
is
a
huge
plus
to
it,
and
if
they
can
link
out
to
the
unfiltered
content
or
wherever
we
end
up
hosting
these
these
speedruns,
then
it
makes
them
very
accessible
as
well
and
we're
just
making
everything
more
accessible
so
we'll
see.
Maybe
it
will
flop.
I
don't
know,
but
you
won't
know
easier
to
try.
So
we're
gonna
go
forward.
C
I
just
mentioned
in
the
agenda
there
that
it
just
kind
of
occurred
to
me
that
as
a
half
way
to
automatically
interacting
with
pipelines,
it's
possible
in
a
pipeline
currently
to
define
a
manual
job
that
requires
the
blocks
and
mr,
until
somebody
does
something
or
checks
something
so
possible,
we
could
automatically
insert
a
job
for
requirements,
management
that
requires
a
manual
check.
So
before
we
have
to
take
the
output
of
jobs,
you
know
packet
for
certain
things
and
and
all
that
automation,
the
first
step
could
be
to
insert
a
manual
check.
C
A
I
think
that's
another
excellent
way
we
could
iterate
on
this
I
think
these
are
great
discussions.
I
think
what
we
probably
want
to
do
is
sort
of
I
love
to
do
today.
Synchronously,
but
I
also
think
that
the
having
the
discussion
is
helpful
as
well
so
I,
don't
know
the
best
way
to
go
about
this,
but
I
think
we
should
start
adding
these
two
that
epic,
that
yawns
were
added
his
ideas
too,
as
well
and
try
to
figure
out.
A
You
know
what
makes
sense,
maybe
that's
the
first
step
toward
yawn
solution,
which
is
the
first
step
toward
a
scraping
solution
and
that
maybe
we
can
define
these
sort
of
simple
steps
we
can
take
over
the
next
few
releases
that
are
very
achievable
and
we'll
show
you
know
immediate
value,
because
I
think
that
description
of
what
you
said
doesn't
require
any
change
on
our
part.
It's
already
there
or
just
using
built-in
mechanisms
in
a
different
way.
We.
B
C
C
A
A
Let's
see
I
believe
the
epic
is
28:59
and
we'll
keep
adding
to
that,
and
then
maybe
we'll
circle
back
next
week
at
some
point
and
kind
of
walk
through
those
and
see
how
we
want
to
take
the
scale
we
want
to
break
them
down
and
just
sort
of
break
that
epic
down
into
individual
steps
and
I'll
start
scheduling
them.
Oh.