►
From YouTube: Plan stage weekly - 2019-12-18
A
So
this
is
the
plan
stage
weekly
meeting
for
the
18th
of
December
2019.
First
of
all,
team
updates,
as
I
mentioned
before
I'm
moving
to
the
scalability
team
on
the
1st
of
January,
we
are
looking
for
new
engineering
managers
to
replace
me
positions.
Open
we've
got
some
people
in
the
pipeline.
John
is
gonna.
Take
interim
management,
the
project
management
team
until
we
do
because
you're
honest,
even
if
we
found
somebody
today
who
we
were
determined,
would
be
the
new
engineering
manager
they
weren't
I've
started
by
the
1st
of
January
John.
B
C
All
right
so
just
wanted
to
walk
through
the
12.7
release,
planning
issue,
real
quick
I'll
go
ahead
and
open
that
up
and
share
my
screen
running
another
experiment
or
warning
see
if
I
can
get
my
computer
to
lock
up
or
not
lock
up.
So,
let's
see
cool
all
right,
so
you'll
see
this
I
think
we
have
our
kickoff
videos.
If
you
want
to
check
those
out
the
at
least
for
project
management,
I
put
my
direction.
C
Two
main
direction
pages
links
there
in
terms
of
validation
cycles,
we're
going
to
start
looking
at
doing
to
news
and
notifications
and
overall
net
in
anticipation
of
maybe
like
starting
in
twelve
eight
twelve
nine,
but
we're
gonna
start
this
with
the
problem.
Validation
and
they'll
move
into
solution,
validation,
same
thing
with
automatic
triaging
labeling
of
issues
that
will
be
further
out,
but
we're
going
to
start
some
of
the
validation
cycles.
Now
in
terms
of
design
priorities,
we
need
to
wrap
up
the
work
on
multiple
milestones
per
issue.
C
Average
of
us
I
think
we're
doing
the
initial
data
migration
now
to
prepare
for
that
and
we're
pretty
close
I
went
ahead
and
broke
out
a
bunch
of
follow-on
work.
They're
like
improving
out.
You
know,
filtering
works
like
on
issue
lists
and
issue
boards,
and
that
sort
of
thing
with
multiple
milestones
and
then
after
we
kind
of
wrap
that
work
up.
C
I
want
to
move
over
to
some
design
work
on
adding
first-class
support
for
a
sheet
task
lists
and
tasks
in
terms
of
features
goal
is
to
get
one
field,
any
field
updating
in
real
time,
using
kind
of
whatever
text
sack.
We
end
up
blaming
them
for
that,
but
just
one
field
and
there's
a
proof
of
concept
and
then
complete
the
NB
c--'s
for
multiple
milestones
and
Mauston
types.
It's
important
to
get
that
done
in
twelve,
seven
anticipation
of
a
demo
we're
doing
for
Gardner
and
January
24th,
and
then
adding
burn
up,
charts
milestones.
C
C
Keenan
I,
don't
believe,
is
here,
but
I'll,
just
kind
of
run
through
his
stuff
right,
quick
design
priorities
would
be
show
milestones
on
a
road
map.
You've
gotta
check
that
out.
If
you
want
to
know
more
providing
confidential
epics,
so
issues
can
be
confidential
epics
can't
we
need
to
kind
of
pair
you
there
and
then
there's
also
this
interesting
feature
for
out
of
having
a
field
that
updates
the
health
status
of
an
issue.
So
you
can
kind
of
check
that
out,
but
it
it
could
be
interesting.
C
D
I
mean
our
design
priorities.
Right
now
are
really
just
continues:
I'm
trying
to
get
the
service
s
Enterprise,
ready.
We've
got
a
couple
issues
out
there,
both
internal
and
external,
where
we're
trying
to
kind
of
bring
some
new
features
that
make
it
more
of
an
enterprise
solution,
we're
continuing
to
worth
requirements,
management,
research
issue
which
is
going
well
and
then
we're
excited
for
our
blocking
issues.
Support
so
there's
a
couple
more
sort
of
following
issues
there
that
iterate
on
the
MVC.
D
So
hopefully
that
will
make
blocking
issues
a
real
thing
that
is
very
usable
for
everybody,
Service
Desk
we're
doing
and
helping
more
things
in
the
service
desk
to
kind
of
make
it
more
configurable,
configurable
email
address
and
we're
fixing
a
bug
that
was
found,
and
then
the
biggest
thing
really
for
us
is
the
requirements.
Management
piece,
we're
gonna
kick
off
the
MVC.
Hopefully
this
release
I
believe
it's
pretty
much
ready
to
go.
We
have
a
little
design
work
to
finish
up
on
that,
and
then
we
should
be
in
good
shape.
C
C
D
So
I'll
try
to
you.
Okay,
let
me
see
that
okay,
so
this
is
the
direction
page
requirements
management.
This
has
been
updated
relatively
recently,
I'm
sure
that
there
will
always
be
more
updates
coming,
so
it
will
continue
to
change.
So
people
can
keep
looking
back
at
this,
but
the
overall
strategy
here
is
that
in
general
for
customers
who
need
requirements,
there's
a
large
amount
of
friction
that
exists
between
your
requirements,
management
tool
and
your
configuration
database
and
your
repositories
and
in
the
requirements
management
space.
D
One
of
the
major
goals
requirements
is
to
tie
them
to
source
code
and
to
tie
them
into
your
testing
so
that
you
can
see
if
I
have
a
requirement.
Where
is
it
tested?
Where
is
it
implemented?
If
the
requirement
changes,
you
want
to
build
a
trace
and
say
hey,
this
requirement
changed
what
source
code
files
need
to
change,
what
tests
need
to
change
and
actually
do
that
regression
analysis.
So
one
of
the
major
things
we're
trying
to
leverage
here
is
because
we're
a
unified
DevOps
tool
chain.
D
We
should
be
able
to
put
all
that
into
one
tool
which
would
make
it
much
better
for
sort
of
the
space
out
there
right
now
nobody's
really
doing
that
integrations
between
some
of
the
major
players,
like
doors,
don't
integrate
back
into
any
sort
of
a
git
repository,
or
things
like
that,
so
it
makes
it
very
difficult
to
kind
of
trace
back
and
forth.
So
that's
sort
of
our
mission
for
people
who
aren't
familiar
with
requirements,
management,
there's
a
link
to
a
good
article
from
PMI
here,
but
effectively.
D
So
this
is
an
opportunity
for
us
to
introduce
that
and
that's
where
the
whole
point
of
requirements
is
to
have
that
regression
ability
to
have
that
traceability
between
different
artifacts
within
your
your
repository.
So
as
I
came
out
of
aerospace,
I
figured
I'd
start
off
with
an
aerospace
use
case.
I'd
like
to
add
more
of
these,
as
we
do
further
customer
interviews,
but
for
regulated
industries,
there's
usually
standards
that
they
have
to
follow.
In
the
case
of
aerospace
and
a
few
other
mission-critical
type
things
it's,
the
RTC
is
do-178b
or
C.
D
People
are
migrating
towards
C,
and
this
is
sort
of
the
overall
requirement.
Well,
its
name
adjust
based
on
requirements.
It's
the
overall
process.
You
must
follow
in
order
to
get
your
flight
control
or
other
aerospace,
critical
items
certified
by
the
FAA
yassuh
a
knack
or
any
of
the
other
survey
agencies,
air,
Transport
Canada.
In
order
for
that
plane
to
fly
within
their
airspace,
they
have
to
certify
everything.
And
in
order
to
do
this,
they
must
be
able
to
show
that
you've
defined
requirements.
You've
implanted
those
requirements,
you
verified
those
requirements
and
tested
to
them.
D
So
the
most
common
trace
paths
that
are
used
all
the
time
is
in
the
system,
level
requirements
which
are
effectively
the
airplane
models
for
an
aerospace
control
system
or
other.
You
know,
system
level
models
and
those
get
broken
down
into
you.
High
little
soft
requirements
which
are
what's
going
to
happen
in
this
particular
box
on
an
airplane
in
this
particular
functionality
of
that
box.
From
there
they
get
broken
down
even
further
into
low
level
requirements,
otherwise
known
as
design.
You
can
do
it
either
way.
D
There
must
be
traceability
up
to
the
high
level
requirements,
so
you'll
break
it
down
and
or
decompose
a
high
level
requirement
say:
okay,
that's
gonna
be
done
by
the
following
three
smaller
requirements
and
then
you
would
have
to
trace
your
source
code
that
implements
those
requirements
to
the
low
level
requirements
and
then
you'd
trace
the
executable
object
code
to
the
source
code.
So
you
can
see
there's
a
lot
of
traceability
required
here
from
a
testing
perspective,
which
is
where
you
get
audited
is
they
will
say:
okay,
here's,
the
high
and
low
level
requirements.
D
What
test
cases
test
that
which
procedures
are
inputting
those
test
cases
and
where
are
the
results
of
those
procedures
and
do
they
pass
or
fail?
So
aerospace
is
a
bit
odd.
You
can't
have
any
quote
dead
code
or
unused
code.
I
realign
of
code
must
trace
to
a
requirement.
You
can't
have
any
code
that
doesn't
trace
directly
to
a
requirement,
so
it's
very
regulated
in
that
sense,
drink
audits.
The
teens
are
asked
to
demonstrate
this
ability,
so
you'll
sit
before
the
FAA
and
they'll
say:
okay,
here's
your
system
load
requirement.
E
D
Are
hoping
to
collaborate
with
verify
team
because
they're
looking
for
artifact
creation
and
artifact
capturing-
and
that
is
part
of
this,
so
yes
as
we
as
we
iterate
on
requirements,
we're
starting
at
the
very
high
level
just
create
requirements,
link
them
to
each
other
and
link
them
to
some
source
code
as
we
get
further
down
the
path
here.
Yes,
we'll
definitely
want
to
create
or
collaborate
closely
with
them,
because
what
I'd
love
to
see
and
nobody
offers
this.
This
could
be
a
huge
thing
for
us.
D
So
that
requirement
is,
let's
say,
green
and
this
requirement
was
tested,
but
it
failed
that
one
could
be
red
and
this
requirement
is
untested,
so
it
would
be
I,
don't
know
another
color,
so
we
could
really
leverage
this
all
together
and
that
could
be
part
of
your
artifact
collection.
So
in
aerospace
at
least
the
test
results
are
artifacts,
they
need
to
be
collected.
So
yes,
we'll
definitely
have
to
collaborate
closely
with
the
verify
team,
as
we
get
further
into
the
traceability
aspects.
D
Thank
you.
Absolutely
I
also
intend
to
find
some
key
terms
and
concepts
for
people
who
are
not
as
familiar
with
requirements.
Lingo.
It
can
be
a
bit
confusing
at
first.
The
really
big
thing
to
point
out
is
one
of
the
key
deliverables
in
every
certification
effort.
Is
this
traceability
matrix,
which
is
essentially
a
giant
and
spreadsheet,
looking
thing
that
shows
the
traceability
in
a
in
a
matrix
form,
and
that
has
to
be
delivered
to
the
customer
and
to
the
cert
agencies
prior
to
going
into
an
audit.
D
So
that's
a
required
thing
that
we
need
to
have
as
an
output
from
our
tools
eventually
not
right
away.
Obviously
so,
where
do
we
start
with
all
this?
Currently,
we
don't
have
any
sort
of
requirements,
management
within
gitlab,
and
that's
sort
of
why
we're?
Why
we're
here
so
we're
in
the
early
stages
we're
doing
a
lot
of
customer
interviews.
They've
been
really
informative.
They've
been
actually
very
interesting
and
we've
been
talking
to
customers
about
what
they're
looking
for
so
we're.
Our
first
step
is
simply
building
out
the
requirements
structure.
D
So
at
a
group
level
this
would
just
be
a
basic
tree
structure
of
requirements
and
that
would
get
us
to
what
I
would
consider
minimal.
With
surety
now
I
know
we're
changing
how
we're
defining
maturity
levels
so
we'll
have
to
work
through
that,
but
that's
sort
of
the
minimum
thing
that
we
could
present
to
people
where
they
could
use
it
from
there.
D
We're
looking
to
integrate
in
link
with
other
artifacts
within
get
lab
test
cases,
test
results
and
to
achieve
some
level
of
traceability
and
that
these
iterations
are
going
to
start
us
working
toward
that
viable
maturity
category
where
people
could
actually
utilize
this
in
a
regulated
industry
from
there.
This
guy
is
kind
of
the
limit,
so
we'll
have
to
kind
of
see
what
our
user
research
shows
as
we
go
forward
past.
D
That
also
related
to
this
category
are
the
release:
governance
from
release
on
particular
the
concepts
for
there
to
evidence,
an
artifact
collection,
so
that
kind
of
goes
back
to
your
point.
Evidence
collection
needs
to
be
able
to
be
traced
to
so
you
have
to
trace
to
these
artifacts
in
this
evidence,
so
we'll
have
to
work
closely
with
them
and
then,
as
I
was
thinking
through
this
I
kind
of
figured.
What
do
we
need
for
an
MVC
and
what
are
all
the
functionality
we
could
potentially
implement?
D
It
doesn't
have
to
be
done
now.
All
this
is
absolutely
required
to
make
the
category
viable
or
even
further
than
that,
but
at
a
bare
minimum
we
need
to
be
able
to
have
the
concept
of
you
know.
Requirements
are
active
or
archived.
We
need
to
have
unique
requirement
identification
somehow,
because
you
you
never
can
lose
a
requirement,
it's
kind
of
one
of
the
tenants.
D
Even
if
you
try
to
change
it
or
delete
it,
it
still
has
to
be
in
the
system
somewhere
and
that
ID
is
what
is
used
throughout
all
these
trading
steps
and
when
you're
talking
to
a
team,
you'll
say
hey,
how
is
requirement.
You
know
how
a
requirement
seventy
seven
where's
that
trace
so
there
needs
to
be
some
sort
of
a
unique
identifier,
and
then
there
needs
to
be
some
sort
of
requirements,
text
which
is
the
actual
requirement
and
then,
from
a
development
perspective,
the
developer
needs
to
add
archive
or
edit
those
requirements.
D
D
D
The
other
thing
is.
We
need
to
be
able
to
have
some
sort
of
visual
representation
of
traceability
and
test
coverage.
This
goes
back
to
the
idea
of
integrating
with
the
CI
CD
pipelines
and
in
showing
how
those
pass
or
fail
requirements,
which
would
be
a
really
awesome
feature
to
add.
I
do
have
a
bit
about
competitive
landscape.
There's
not
a
lot
of
tools
out
there
that
are
widely
used
in
regulated
industries.
D
I
know,
there's
a
lot
of
tools
used
to
manage
requirements
and
other
industries,
but
the
main
competitors
are
IBM
rational
doors,
which
is
pretty
much
where
everybody's
at
right
now
and
there
is
a
JAMA
connect
tool
which
integrates
sort
of
with
JIRA,
but
it's
not
widely
utilized
because
it
doesn't
actually
allow
importing
and
exporting
from
doors
correctly
and
since,
at
some
level,
every
program
uses
doors,
that's
been
a
major
limiting
factor
for
them.
We
are
doing
more
in
the
analyst
landscape.
D
We've
been
working
closely
with
some
the
analysts
to
kind
of
figure
out
where
this
the
market
is
going
with
requirements.
There's
not
a
lot
of
movement
here.
A
lot
of
these
industries
using
this
are
very
regulated
and
therefore
things
that
come.
Don't
tend
to
go
away
easily,
they
don't
switch
tools
for
these
types
of
things
very
often,
so,
there's
there's
not
a
lot
in
that
industry.
D
What
we're
looking
more
for
the
analysts
to
do
is
tell
us
what
else
is
used
for
the
less
rated
industry
is
people
who
are
trying
to
implement
like
GD
P
R
and
want
to
have
requirements
behind
that
and
I
do
have
the
minimum
maturity
level
linked
here.
There's
an
epoch
out
there
I've
been
putting
things
in
so
people
can
click
through
that.
There's
no
issues
out
there
yet
because
we
don't
have
anything
people
very
issues
against
and
then
internal
customers.
D
The
quality
department
is
experimenting
with
the
idea
requirements
management,
so
we'd
like
to
collaborate
with
them
as
we
move
forward,
and
hopefully
they
can
help
us
dog
food.
This
as
we
move
forward
because
there'd
be
one
of
the
first
people,
probably
internally.
You'd
want
to
get
on
board
with
this.
I
also
hope
to
use
this
on
the
certify
team.
Just
so
we
can
dog
food
around
product
and
people
can
really
understand
it.
So
I
also
have
our
requirements.
D
The
group
level,
epic,
which
are
issue
which
is
what
we're
hoping
to
implement
in
twelve
seven
and
then
I,
also
have
a
link
here
to
the
initial
discussion.
I
had
I
did
a
YouTube
thing:
it's
not
on
a
filter
that
kind
of
discusses
what
our
requirements.
So
people
who
haven't
been
in
a
colleague
that's
where
I've
gone
through
it
or
just
want
for
the
reference
they
can
go
ahead
and
watch
that
any
questions.
F
D
Yes
and
no
I
mean
most
tools
will
import
CSV
files.
The
issue
comes
down
to
one
of
the
reasons
doors
has
retained
its
sort
of
spot
is
it
supports
the
idea
of
creating
attributes
for
requirements,
and
so
some
projects
will
have
tons
and
tons
of
attributes.
Things
like
safety,
critical
or
needed
for
first
flight
are
things
we
used
a
lot,
but
when
you
export
those,
they
don't
export
correctly
from
most
tools
and
then
doors
can't
pull
them
in
and
see
if
those
are
attributes
on
a
requirement.
D
So
as
we
go
through
this
we're
working
kind
of
hard
to
figure
out,
how
can
we
have
a
flexible
system
that
allows
us
to
down
the
road
support
attributes?
On
top
of
just
you
know,
requirement
identifiers
in
text.
Oftentimes
large
industry
needs
attributes
to
define
further
subsets,
it's
almost
like
labels,
but
they
can
contain
a
lots
of
text
so
how
a
lot
of
people
do
indoors
right
now,
because
it
doesn't
integrate
correctly
with
their
configuration
management
tools.
D
D
D
D
C
Based
on
kind
of
some
conversations
about
having
ongoing,
there's
some
issues
in
the
plan
project,
just
about
capacity
allocations
and
like
wanting
to
dog
food
that
a
little
bit
more
and
understand
things
I
started
the
merge
request
so
that,
hopefully,
the
engineering
managers
can
add
like
specifically
how
capacity
is
planned
for
and
then
like
what
is.
Our
historical
capacity
has
been
in
our
approach
that
this
is
like
in
response
to
an
ongoing
lots
of
teams.
Ask
me
how
that
works
and
I
don't
know
entirely
and
then
I
also
know
like.
Sometimes
we
overestimate
our
craft.
C
So
your
underestimate
our
capacity
and
it's
kind
of
like
a
black
box
and
so
I
think
being
a
little
bit
more
transparent
about
that
process
to
be
helpful
and
then
we're
also
gonna
use
whatever
like.
However,
it's
currently
working
to
build
out
some
models
and
periscope
so
that
we
can
start
having
some
dashboards
for
this
I.
Think
in
one
of
the
issues
we
talked
about,
maybe
looking
at
issue
weight
is
like
a
standard
progress
metric
that
boats,
like
that
cross-functional
teams
align
behind
so
based
on
John's
comment.
C
I
agreed
that
it
should
or
could
go
on
team
pages,
or
we
can
roll
it
up
on
no
single
on
I.
Don't
really
have
a
preference,
since
whatever
y'all
want
to
do
but
I
think
just
like
being
transparent
about
it
and
the
process
would
be
really
helpful.
It's
anybody
have
any
feedback
about
that
or
push
back.
A
A
A
I
think
it's
kind
of
a
challenge
because
the
sort
of
details
belong
to
the
teams,
but
then
the
output
prolongs
to
the
p.m.
which
spans
teams,
because
from
gaben
marks
perspective
and
Keenan
as
well
who's.
Not
here
like
their
concern
is
like.
Can
we
do
this
stuff?
Not?
Can
we
do
the
backend
stuff,
or
can
we
do
the
front-end
stuff?
So
it's
it's
difficult
to
balance
those
two
out,
but
hopefully
we
can
come
up
with
a
good
solution.
C
This
part
of
also
the
issue,
tasks
and
issue
task
lists.
One
of
the
goals
of
that
is
to
make
it
so
that
you
can
like
have
a
task
list
and
and
wait.
It
wait
each
task
separately
and
then
those
would
all
aggregate
into
the
overall
issue
wait.
So
it's
easier
they're
like
split
out
front
and
back-end
work,
but
have
that
combined
into
not
yet
I
found
in
her
time
there
it
doesn't
like.
C
So
that's
kind
of
where,
like
I,
don't
I,
don't
want
to
use
it
to
look
at
each
team
or
look
at
user
to
look
at
the
aggregate
as
a
whole
kind
of
like
what
I
was
saying
so
wherever
y'all
feel
like
it's
best
for
that
to
live,
but
I
really
don't
have
a
strong
preference
just
that
we
like
get
it
down
and
documented
it
and
then
I
think
Donald
volunteered
to
help
me
I'll
work
on
the
periscope
page
too
and
I
that
you
have
to
job.
If
we
get
stuck
so.
A
Cool,
so
next
week
is
the
25th
of
December,
which
is
a
holiday
in
a
bunch
of
countries
the
week
after
that,
it's
the
1st
of
January,
which
is
a
holiday
in
a
bunch
of
countries,
so
I
mean
I,
suggest
that
we
cancel
the
school
for
the
next
two
weeks
on
the
assumption
that
a
bunch
of
people
won't
be
here
and
then,
after
that,
I
will
move
ownership
of
the
calendar
event
and
the
meeting
to
gave
so
that
you
can
run
this
going
forward
yeah.
This
is
my
last
one
takes
everybody.
A
A
C
One
other
thing:
sorry
right,
quick
before
we
go
is
we
did
hire
an
external
group
product
manager
for
plan,
so
they'll
be
starting
February,
10th
I
think
his
name's
Justin
it's
coming
over
from
Zillow,
so
I
would
assume
you
probably
will
take
ownership
of
the
calendar
of
it
at
that
point.
But
I
am
happy
to
Shepherd
it.
Please
yeah.