►
From YouTube: Agile Portfolio Demo
Description
Provides an overview of an Agile portfolio demo using data populated with the GitLab data seeder.
A
Hi
everyone,
my
name,
is
Julie
Byrne
and
I'm.
A
senior
solution
architect
on
the
commercial
team.
I
am
going
to
take
you
today
through
a
new
project
that
I
have
just
contributed
to
the
Cs
share
demo.
Space
on
learn,
labs
and
I'm
really
excited
about
this,
because
it
is
something
that
I've
been
working
on
with
a
group
of
people
for
quite
some
time
in
terms
of
producing
realistic
demo
data
for
which
we
can
demonstrate
agile
portfolio
and
project
planning
and
tracking,
and
there
has
been
a
whole
working
group
that
has
been
participating.
A
I'd
like
to
thank
Grant,
young
and
Dan
Davison
for
providing
their
guidance
and
expertise
and
I'd
really
like
to
thank
Siddharth
Mather
as
well
for
doing
a
couple
of
things.
First
of
all,
creating
an
export
Tool
that
allowed
me
to
export
my
current
group
and
project
data
for
my
demo
instance
into
a
ruby
format
that
the
data
center
will
then
suck
in
to
create
new
demo
data.
A
There's
a
bit
of
massaging
of
the
the
Ruby
code
that
we
have
to
do
in
the
process
after
the
export,
but
it
was
a
great
starting
point,
so
we
didn't
have
to
start
from
scratch,
and
so
let
me
take
you
through
a
bit
about
what
this
project
looks
like
if
I
forgot,
anyone
in
the
demo
work
data
working
group.
Thank
you
all.
It's
been
a
great
experience,
spency.
Thank
you
too.
All
right.
Everyone
here
is
the
project.
A
A
A
A
The
instructions
take
you
through
just
spinning
up
gitlab
in
a
Docker
container
and
then
installing
the
appropriate
test,
resources
and
copying
the
Ruby
file
over
to
the
correct
place
and
then
running
the
cedar.
So
you
can
follow
that.
Here's!
What
I
like
about
this
approach,
particularly
for
agile
portfolio
and
project
management,
we're
able
to
define
a
standard
group
and
project
hierarchy?
A
Labels
are
used
at
both
the
Epic
and
the
issue
level,
and
then
I
created
a
label
specifically
for
initiative,
type
epics
and
that's
initiative
theme
and
that's
for
more
of
the
portfolio
level.
Business
planning
aspect
of
things
that
you'll
see
in
the
demo
and
to
define
a
hierarchy
of
epics
with
initiatives
as
the
top
level
and
features
as
the
second
level
and
some
epic
boards
and
some
individual
project
level.
A
Issue
boards,
as
well
as
I,
said
there
is
a
Wiki
page
here,
so
you
can
go
and
click
that
link
and
it
does
give
you
a
script
for
how
to
use
the
demo
data
that
you're
going
to
seed
into
your
gitlab
instance
to
show
agile
portfolio
and
project
planning.
Again
this
is
an
MVC
there's
some
enhancements.
We
can
do
some
wording
tweaks
and
better
showing
the
value
proposition
in
some
cases,
but
I
think
this
is
a
really
good
starting
point
to
get
us
to
consistently
reproducible
usable,
agile
demos.
A
A
So
Sid
and
I
are
going
to
continue
to
work
on
that
and
we
would
love
for
others
to
join
us
in
this
effort
and
continue
to
build
out
an
entire
end-to-end
demo
flow
that
we
can
easily
import
into
a
gitlab
instance,
and
you
know,
use
and
have
it
clean
and
fresh.
Every
single
time
we
do
a
demo,
so
that's
the
goal
well
now
I'm
going
to
actually
take
you
through
this
demo
flow
that
I've
defined
for
agile
portfolio
planning
and
tracking.
So
I
ran
the
data
theater
and
it
created
this
gold
agile
program.
A
You
can
change
the
name
of
that
to
whatever
you
want
here.
I
have
a
group
and
project
structure
that
reflects
a
set
of
teams
working
together
in
an
agile
program.
In
this
case,
we
have
a
one-to-one
mapping
in
terms
of
the
way
that
teams
work.
So
we
have
one
team,
that's
working
on
the
online
shopping
site
and
one
team,
that's
working
on
the
corporate
website
and
we
have
a
security
project
for
policy
enforcements
that
we're
going
to
do
later
on
as
an
enhancement.
A
A
So
if
we
created
two
different
program-
increments
Pi,
one
and
pi2-
we're
in
the
beginning
of
program
increment
one
right
now
in
the
first
iteration
of
program,
increment,
one
I
should
point
out,
and
the
one
thing
I
forgot
to
point
out
in
the
data
center-
that
let
me
go
back
to
that
first,
because
it's
really
important.
All
of
these
dates
are
relative
dates.
So
when
you
start
to
look
through
the
the
Ruby
file
that
was
created,
oops
see
the
Ruby
file
that
was
created
here.
A
You
will
notice
that,
as
we
are
creating
the
different
types
of
objects,
let
me
see
if
I
can
find
a
milestone
quickly,
anything
that
has
a
date
associated
with
it.
We
have
relative
dates
that
can
be
used
so
great.
You
can
use
days
weeks
months.
You
can
add,
so
you
can
say
eight
days
ago,
plus
two
weeks
as
an
end
date
for
an
iteration
as
a
an
example.
So
this
is
really
one
of
the
keys
to
this
pretty
demo
data
that
we
can
use
for
agile.
A
The
other
one
is
in
creating
the
burn
charts.
There
is
resource
event.
There
are
a
set
of
resource
events
that
have
to
be
created
every
time
you
add
an
issue
to
an
iteration,
add
an
issue
to
a
milestone.
Wait
the
issue
close
the
issue.
We
open
the
issue.
Those
are
all
events
that
get
logged
in
the
database
that
influence
what
you
see
on
the
burn
charts
right,
so
that
data
is
used
to
generate
the
burn
charts.
So
if
I
just
look
for
a
resource
event,
so
here's
a
set
of
events.
A
We
have
for
an
issue,
a
weight
event,
a
milestone
event.
There
are
status
events
or
state
events,
I
forget
what
it's
called
and
iteration
events
as
well.
So
take
a
look
through
all
of
that
in
the
Ruby
file
that
seeds,
the
data
and
you'll
start
to
see
how
all
of
this
comes
together
for
pretty
demo
data.
A
Okay
back
to
our
demo.
So
we
start
by
introducing
the
concept
of
a
group
representing
an
agile
program
and
the
project
representing
teams.
And
then
we
talk
about
planning,
cadences
program
increment,
one
and
program
increment
two
are
mid-range
planning,
time
boxes
that
we're
using
and
then
for
iterations.
We
defined
a
standard,
iteration
Cadence
that
are
two-week
sprints
and
once
we
have
all
of
that,
both
of
the
teams
are
working
on
the
same
cadences
same
iteration,
Cadence
and
the
same
program
increment
Cadence.
A
Once
I
have
talked
about
that
basic
setup
in
terms
of
structure
to
support
agile,
then
I
like
to
go
to
the
Epic
list.
So
here
we
can
see
the
high
level
initiatives
or
projects
that
we're
working
on
and,
in
our
case,
we're
going
to
use
an
epic
hierarchy.
So
we
have
two
different
types
of
Ethics
defined,
a
top
level
initiative,
and
then
we
will
break
down
or
decompose
those
initiatives
into
individual
features
that
the
teams
can
work
on
and
Implement
within
one
mid-range
planning
Cadence.
A
So
we
can
see
that
we're
using
scope
labels
to
Define,
which
are
the
initiatives
and
which
are
the
features,
and
we
do
have
the
features
parented
up
to
initiatives
in
most
cases
and
we'll
see
that
on
the
roadmap.
But
you
will
also
see
that
in
any
initiative,
Details
page
what
the
parent
epic
is.
If
there
is
one
we
have
a
standard
set
of
labels
that
we're
using
to
track
our
status
just
to
check
the
workflow
of
both
the
initiative
or
sorry,
the
Epic,
and
also
the
underlying
issues.
A
Portfolio
managers
like
to
be
able
to
correlate
the
different
initiatives
that
they
are
defining
and
prioritizing
with
the
different
pillars
or
themes
that
an
organization
has
defined
for
development,
in
terms
of
where
they're
going
to
focus
their
development,
spend
I've
actually
created
a
board
called
initiatives
by
theme.
So
we
can
start
to
as
a
portfolio
manager
see
how
many
different
initiatives
do.
We
have
in
each
theme
get
to
the
details
of
those
initiatives
see
when
we're
planning
to
start
and
end
those.
A
We
can
open
the
initiative,
details
of
course
and
then
see
how
the
initiative
is
progressing
in
terms
of
work
breakdown
to
features
and
then
feature
breakdown
to
story.
So
if
I
open
the
cloud
native
shopping
app
here,
I
can
see
the
hierarchy
of
the
different
features
that
we
have
defined
for
this
particular
initiative,
and
we
can
drill
down
further
and
see
the
underlying
stories
that
have
been
defined
by
the
product
owners
for
each
feature
that
are
going
to
be
implemented
by
the
teams
working
on
these
different
applications.
A
So
it's
great
to
be
able
to
see
the
epics
in
a
list
View
and
manage
them
with
labels.
It's
also
great
to
be
able
to
manage
them
on
a
board
to
just
drive
better
visibility
and
prioritization
on
the
boards.
We
can,
you
know,
drag
and
drop.
If
we
think
that
something
is
in
the
wrong
category
Associated
to
the
wrong
theme,
we
can
move
it
to
the
other
column
to
add
the
appropriate
theme
to
it.
A
We
also
have
the
ability,
of
course,
to
create
new
initiatives
here,
as
we
go
and
just
have
them
automatically
associated
with
the
appropriate
theme,
based
on
the
column
that
we
are
creating
the
initiative
in
once.
I
have
my
initiative
organized
and
prioritized.
Oh
I
can
also
drag
and
drop
term
re-rank
prioritize
the
initiative,
so
that
is
something
that's
helpful
for
a
portfolio
manager,
who's
trying
to
understand
what's
highest
priority
once
I
have
all
of
that
defined.
A
How
do
we
start
to
plan
for
when
initiatives
and
corresponding
features
will
be
released
and
available
to
our
customers?
That's
all
defined
in
our
roadmap
View,
and
here
we
have
a
nice
roadmap
view
that
shows
our
top
level
Initiative
for
cloud
native
shopping
app.
It
also
shows
the
underlying
features
Associated
to
our
Cloud
native
shopping
app.
These
are
the
features
we're
going
to
implement
to
complete
this
initiative
and
we
can
see
progress
reporting,
so
we
can
actually
see
for
those
features
based
on
the
issues
defined
for
those
features,
how
much
progress
we're
making.
A
In
this
case,
we
are
reporting
based
on
the
weight
of
the
issues,
think
story,
points,
values
or
plan
estimate
values
on
each
of
those
issues.
If
you
don't
size
your
stories
and
default
bug
fixes,
you
can
then
just
use
account
of
issues
instead
of
weight,
but
this
roll
up
goes
all
the
way
from
the
features
all
the
way
up
to
the
top
level
parent
Epic.
A
So
we
can
see
the
progress
we're
making
on
the
initiative
as
a
whole
as
well.
So
this
is
really
great.
We
can
dig
into
additional
details
if
we
would
like
just
to
see
you
know
where
we're
making
progress.
Progress
where
we
might
be
stuck
I
can
go,
for
example,
and
open
this
one
click
checkout
feature
to
see
the
details
of
it.
A
A
Now
again
we
have
our
standard
status,
scoped
labels
to
track
the
workflow
from
it
being
in
our
backlog
to
in
progress
to
awaiting
acceptance
by
the
product
owner
and
then
once
they
are
closed.
That
means
that
they're
done
done.
We
can
also
see
the
weight
that
we've
added
to
each
of
these
issues.
This
is
our
size
of
the
the
stories
and
Bug
fixes
that
we're
implementing,
and
we
can
see
that
each
of
these
are
scheduled
into
our
mid-range
planning,
time
box
or
program
increment
one
milestone.
A
We
can
also,
then
see
the
individual
issue
details
just
by
clicking
on
the
link
to
each
individual
issue.
So
here's
our
change,
image
and
background
issue,
and
we
can
see,
for
example,
that
it's
in
program
increment
one.
We
can
also
see
the
iteration
that
the
issue
is
scheduled
for.
We
are
currently
working
through
our
first
iteration,
which
started
May,
25th
and
ends
on
June
7th
and
that's
what
this
particular
issue
is
scheduled
into.
A
A
Now
this
makes
me
curious
to
see
what
else
is
scheduled
for
current
iteration.
What
is
the
team
working
on
as
a
whole
and
there's
a
couple
of
different
ways
that
we
can
go
about,
seeing
that
one
is
to
open
up
the
iterations
and
start
to
look
at
the
details
of
the
current
iteration,
and
here
we
can
see
our
burn
chart,
burn,
charts,
plural,
there's
a
burn
down
and
a
burnt
up.
We
can
see
the
data
by
the
count
of
issues
or
by
the
total
issue
rate,
and
here
we
can
see
it's
interesting.
A
We're
in
this
online
shopping
site
teams,
iteration
burned
down,
so
we're
looking
at
one
individual
team.
We
can
see
that
they
started
off
pretty
well,
they
got
a
little
stuck
and
then
all
of
a
sudden.
Something
happened
yesterday
and
we're
not
quite
sure
what
so.
This
is
interesting,
but
now
the
team
is
getting
closer
to
the
end
of
their
iteration
and
not
on
track
to
complete
their
work
on
time.
A
A
A
Now
we
can
go
and
look
at
all
of
the
individual
issues
we
can
see
here,
which
ones
are
still
in
progress
and
which
are
closed
and
that's
going
to
be
helpful.
We
can
open
up
any
one
of
these
issues
to
take
a
look
at
them,
but
I
like
to
use
the
board
view.
It's
just
a
little
bit
easier
to
kind
of
see
where
things
are
at
so
I
have
a
Sprint
tracking
board
under
issue
boards
that
I've
created
the
team
uses
this
to
make
sure
that
they're
managing
their
work
effectively
throughout
the
Sprint.
A
A
This
is
a
name
of
a
feature.
One
click
checkout
is
one
of
those
features
we
saw
before
and
that's
you
know
the
work.
The
bulk
of
the
work
that
we're
focused
on
right
now
is
for
one
click
checkout,
and
we
can
see
that
there
are
a
couple
of
issues
without
a
parent
one.
Is
this
improved
load
time?
This
is
a
bug
that
is
high
priority,
starting
to
realize
that
this
may
be
the
cause
of
the
scope
problems
that
we
are
encountering
in
this
iteration.
A
We
can
also
see
this
app
container
update,
app
container
story
doesn't
have
a
parent.
This
could
have
been
a
mistake.
The
product
never
forget
to
parent
it
to
a
feature,
and
if
that's
the
case,
then
we
can
drag
and
drop
to
the
appropriate
column
to
parent
it
to
the
correct
feature
on
this
on
our
board.
So
if
it
should
have
been
part
of
one
click
checkout
great,
if,
if
not,
we
can
just
leave
it
or
we
can
edit
it
through
the
details
page
as
well
and
find
the
appropriate
parent
for
it.
A
This
improved
page
load
time
is
something
then
I
really
want
to
dig
into.
So
we
can
go
ahead
and
open
this
as
well.
Now
there
is
a
Off
Script
for
a
moment.
There
is
a
known
issue
with
opening
details.
Pages
you'll
notice,
I've
been
opening
I
had
all
of
the
pages
opened
already
I
forgot
to
open
this
one
before
the
demo.
The
known
issue
is
that
the
details-
Pages
URLs,
are
not
rendering
correctly
on
data
Imports
and
it
is
something
that
we
have
reported
and
are
hoping
to
get
a
fix
for.
A
So
let
me
just
put
this
one
in
now:
we're
going
to
go
back
into
demo
mode
and
here's
our
improve
page
load
time,
and
now
we
can
see
that
this
was
a
an
issue
that
was
recently
created.
It
was
created
one
day
ago
and
it
was
planned
into
our
iteration
and
waited
one
day
ago.
So
this
is
the
team's
increase
in
scope,
mid
iteration,
but
it
is
a
high
priority
bug
that
they're
working
on
fixing.
A
A
We
have
this
Five
Point
story,
though,
to
update
the
database
schema
that
we're
probably
not
going
to
get
to
as
a
team
in
this
iteration,
given
the
number
of
days
left
in
the
iteration.
So
what
we
can
do
is
we
can
go
ahead
and
re-plan
this
one
in
this
update
database
schema
into
the
next
Sprint,
so
I
can
go
ahead
again
open
this
one
up.
Look
at
the
details.
I
should
have
opened
this
ahead
of
time.
Okay,
look
at
the
issue
Details
page!
A
A
Now
we
have
that
moved
out
to
the
next
iteration
and
now,
when
we
go
back
to
our
burn
down
chart,
we
are
going
to
be
able
to
refresh
and
see
that
we
are
fixing
our
scope
problems
in
this
iteration,
so
decrease
in
total
scope.
We
look
at
by
weights.
It's
even
better
gets
us
down
below
that
ideal
burn
line.
A
Hopefully,
now
we
will
be
able
to
complete
the
rest
of
the
three
remaining
stories
by
the
end
of
the
Sprint,
based
on
this
lower
smaller
scope
that
we
have
remaining
now
due
to
replanting
that
other
issue,
so
the
burn
down
charts
are
really
valuable.
They
give
us
a
great
view
of
progress
and
where
there
are
bumps
in
the
road,
so
to
speak.