Master the principles and practices of agile software development and achieve complete agility with Eijel.

1.
Mastering
Agile
Achieve
complete
agility
with
Eijel
Dondon
Vizcayno
Founder
of
Eijel

2. Copyright
©
2014
by
Dondon
Vizcayno
All
rights
reserved.
No
part
of
this
book
may
be
reproduced
in
any
form
or
by
any
electronic
or
mechanical
means,
including
information
storage
and
retrieval
systems,
without
permission
in
writing
from
Dondon
Vizcayno,
except
by
a
reviewer
who
may
quote
brief
passages
in
a
review.
First
Edition

3. Contents
5
Introduction
6
What
You
Will
Get
7
The
Incompleteness
Chasm
8
The
Ladder
9
Achieve
Complete
Agility
10
A
Sample
Project
11
Client
Needs
A
Website
12
And
Also
Mobile
Apps
13
Meet
the
Project
Plan
14
Embracing
Agile
Development
15
Eijel
16
An
Anchor
to
Reality
17
Creating
Your
Account
18
Creating
Your
Projects
20
Project
21
A
Context
for
Everything
22
When
a
Project
is
Deleted
23
Sprints
24
Managing
all
the
Sprints
26
Updating
and
Deleting
Sprints
27
Scrum
Team
28
Building
Your
Team
30
When
Members
and
Roles
Change

4. 31
Product
Backlog
32
What
Needs
to
Be
Delivered
34
Reorganizing
the
Priority
35
Assigning
Points
and
Playing
Poker
39
Viewing
the
Burndown
Chart
40
Wiki
41
Maintaining
Living
Documents
43
Uploading
Images
44
Sprint
45
How
Much
Work
Can
Be
Done?
48
Doing
the
Actual
Work
52
Progressing
the
Tasks
54
Closing
a
Sprint
56
Viewing
the
Burndown
Chart
57
Bug
Tracker
58
Managing
Project
Defects
61
Software
Engineering
62
Serve
the
Developers
63
The
Value
of
Quality
Code
64
Conclusion
65
A
Promise
Kept
66
Succeeding
in
Your
Projects

5. Introduction
What
You
Will
Get
The
Incompleteness
Chasm
The
Ladder
Achieve
Complete
Agility

6. What
You
Will
Get
I
promise
you
three
things
In
reading
this
book
I
promise
you
will
get
three
things:
1. You
will
know
how
to
do
agile.
2. You
will
know
how
to
achieve
complete
agility.
3. You
will
know
how
to
master
agile.
And
if
you
give
effort
in
doing
item
1
above,
I
will
give
you
a
fourth
promise:
4. You
will
succeed
in
doing
all
items
above.
You
will
achieve
mastery.

7. The
Incompleteness
Chasm
Why
companies
fail
at
agile
The
incompleteness
chasm
is
the
main
reason
why
many
companies
fail
at
agile.
It
is
the
gap
that
separates
companies
successfully
doing
agile
from
those
trying
and
yet
failing
to
get
into
it.
It
is
something
that
must
be
crossed,
or
the
company
will
fall
short
in
its
transformation
and
will
revert
back
to
its
old
ways.
You
will
need
a
ladder
to
cross
this
chasm.
The
ladder
represents
a
solution
to
an
incompetency:
1. Companies
don’t
know
how
to
do
agile.
They
have
an
idea,
but
it
is
flawed.
2. Even
when
trained,
they
can’t
relate
what
they
have
learned
to
what
they
are
currently
doing.
3. The
training
will
fade
like
a
dream.
It
is
over
and
trainees
will
go
back
to
their
jobs
bringing
a
story
of
an
ideal
world
called
“agile”.
It
won’t
change
anything
after
wards
though.
4. And
if
and
when
the
company
finally
gets
what
agile
is,
it
overwhelms
them.
They
can’t
transform.
The
current
is
always
easier.
5. Companies
rarely
hire
agile
coaches.
But
trainings
don’t
help
them
either.
Companies
don’t
know
what
to
do,
and
if
they
know,
they
don’t
know
how
to
do
it.

8. The
Ladder
A
ladder
to
cross
the
incompleteness
chasm
A
company
successfully
doing
agile
is
separated
by
a
mindset
and
a
collection
of
practices
from
another
company
that
fails
at
it.
This
is
the
chasm
that
the
failing
company
must
cross.
How
can
it
get
the
mindset
and
the
set
of
practices
present
in
the
other
company?
What
is
the
ladder
it
can
use
to
cross
the
incompleteness
chasm?
Should
it
hire
an
agile
coach,
send
the
team
into
more
training?
My
answer
is
simple.
I
introduce
to
you
Eijel.
Eijel
is
a
tool
that
will
empower
you
to
have
the
mindset
and
the
practices
to
emulate
the
companies
successful
at
agile.
Eijel
is
a
ladder
that
will
help
you
cross
the
incompleteness
chasm.
Why?
Because
it
will
help
you
achieve
complete
agility.

9. Achieve
Complete
Agility
A
complete
solution
for
doing
agile
When
a
company
crosses
the
chasm
and
becomes
good
at
agile,
it
achieves
complete
agility.
It
achieves
the
minimum
to
be
really
good
at
something.
It
has
completed
the
requirements.
And
with
time
and
practice,
becomes
master
at
it.
The
requirements
for
a
company
to
achieve
complete
agility
are:
1. It
knows
the
principles
and
values
behind
agile.
This
is
the
why
of
agile.
2. It
knows
the
practices
of
agile
and
knows
how
to
do
them
in
real
life.
This
is
the
how
of
agile.
3. It
has
the
will
of
really
following
the
principles
and
really
doing
the
practices.
4. It
is
doing
its
best
to
implement
this
will,
no
matter
how
imperfect.
5. It
aims
to
excel
and
master
the
execution
of
the
will.
The
will
of
agile
can
have
a
physical
manifestation.
A
concrete
embodiment
that
represents
the
abstract
concept.
The
will
of
agile
is
the
ladder
that
helped
the
company
cross
the
chasm.
The
will
of
agile,
in
this
book,
is
represented
by
Eijel.
The
next
chapter
will
introduce
the
context
in
which
you
will
learn
complete
agility.

10. A
Sample
Project
Client
Needs
A
Website
And
Also
Mobile
Apps
Meet
the
Project
Plan
Embracing
Agile
Development

11. Client
Needs
A
Website
Learning
with
a
goal
It
is
best
to
learn
new
things
by
solving
a
problem
using
the
lessons
as
a
solution.
I
will
give
you
a
client
with
a
project
that
needs
to
be
delivered
using
agile.
The
client,
Urela,
is
a
start-­‐up
that
collects
promotions
of
different
shops
and
provides
them
to
users
through
its
mobile
apps
and
website.
The
users
will
be
categorized
as
publishers,
consumers,
and
admins.
The
publishers
will
use
the
website
for
posting
their
promos.
They
can
select
the
specific
shops
that
provide
the
promotion
and
set
the
start
date
and
end
date
when
the
promotion
is
valid.
They
can
also
set
the
title,
the
details,
and
the
image
for
the
promo.
The
client
demands
that
the
website
be
operational
after
3
months.

12. And
Also
Mobile
Apps
Adding
complexity
to
the
goal
The
client
also
wants
mobile
applications
for
Android
and
iOS
to
display
the
content
posted
by
the
publishers.
The
user
should
be
able
to
browse
promos
that
are
nearest
to
his
current
location.
He
should
be
able
to
subscribe
to
shops
and
browse
promos
of
shops.
In
both
the
website
and
the
mobile
apps,
a
user
should
be
able
to
create
an
account
and
must
be
required
to
authenticate
before
he
can
use
the
services.
The
mobile
apps
should
be
delivered
within
3
months.

13. Meet
the
Project
Plan
The
old
way
of
doing
things
In
a
traditional
waterfall
project,
the
plan
to
complete
Urela
will
look
like
this:
Phase
Duration
January
February
March
Planning
1
week
Analysis
4
weeks
Design
2
weeks
Development
2
weeks
Testing
2
weeks
Release
1
week
Most
software
development
projects,
if
not
all,
have
the
goal
of
producing
working
software
at
the
end
of
the
project.
However,
you
can
see
from
the
plan
how
much
is
allocated
to
the
part
where
the
real
action
is,
development.
The
first
three
phases
will
be
filled
with
the
preparation
and
creation
of
documents,
which
will
be
later
on
signed-­‐off,
as
contracts
to
which
software
will
be
developed
and
be
tested
against
later
on.
This
approach
has
the
following
characteristics:
1. There
is
no
room
for
mistake.
Signed
off.
2. There
is
no
room
for
unknown,
ambiguous,
or
changing
requirements.
3. There
is
no
room
for
unpredictable
events
that
can
affect
the
plan.
4. There
is
no
room
for
feedback
or
client
verification.
Surprise
at
the
end.
5. The
chance
of
burning
developers
is
very
high.
Because
they
are
the
one
really
accountable
for
the
working
software.
Meet
the
deadline.
6. The
chance
of
slippage
is
very
high.
It
was
intended
to
be
deterministic.
7. Poor
model
for
long
and
on-­‐going
projects.
Not
sustainable.

14. Embracing
Agile
Development
A
better
approach
to
software
development
Agile
development
aims
to
provide
the
solution
to
the
weaknesses
of
the
waterfall
model.
It
excels
in
doing
this,
and
more.
The
only
problem
is
that
many
companies
still
do
waterfall
primarily
because
of
ignorance
and
because
of
resistance
to
change.
And
those
that
attempt
to
move
into
agile
fall
victim
to
the
incompleteness
chasm,
making
them
go
back
to
what
worked
before,
the
waterfall.
Here
is
where
Eijel
helps
you.
We
will
use
Eijel
in
developing
and
delivering
the
product
for
Urela.
You
will
learn
the
principles
and
actually
do
the
practices
of
agile
by
using
Eijel.
I
am
not
going
to
bombard
you
with
facts
and
info
about
agile.
You
will
learn
a
principle
or
a
practice,
only
in
the
right
context,
and
when
it
is
needed
in
creating
the
product
for
Urela.
We
are
now
about
to
create
our
first
project.

15. Eijel
An
Anchor
to
Reality
Creating
Your
Account
Creating
Your
Projects

16. An
Anchor
to
Reality
Eijel
is
an
anchor
to
reality
Before
we
start
using
Eijel
in
creating
the
solution
for
Urela,
I
would
like
to
explain
why
I
choose
the
approach
of
using
a
tool
in
teaching
agile
development.
The
answer
is
simple.
Eijel
is
an
anchor
to
reality.
A
trainer
might
use
index
cards
in
explaining
the
concept
of
the
product
backlog
in
an
agile
project.
For
him,
the
index
card
is
an
anchor
to
reality.
The
collection
of
index
cards
represents
a
list,
which
is
a
physical
manifestation
of
the
product
backlog.
Eijel
achieves
this,
and
more.
It
does
not
only
represent
a
manifestation
of
an
abstract
concept,
but
as
I
have
shared
earlier
in
the
topic
of
the
incompleteness
chasm,
it
represents
the
will
of
agile
–
the
principles
and
practices
of
complete
agility.
When
you
think
of
agile,
you
can
treat
Eijel
as
the
anchor
to
reality,
the
physical
manifestation
of
the
idea.

17. Creating
Your
Account
Create
your
login
account
To
create
you
account,
go
to
http://eijel.com/signup.
Eijel
accounts
are
free.
Fill
up
the
form
and
then
submit.
Eijel
will
send
you
an
email
to
confirm
your
registration.
After
this,
you
can
login
to
your
account.

18. Creating
Your
Projects
Manage
multiple
projects
After
you
login
in
Eijel,
you
will
see
the
Project
Dashboard.
But
as
you
don’t
have
yet
any
projects,
it
will
show
a
message
that
you
need
to
set
an
active
project.
If
you
will
try
to
explore
the
different
pages
in
the
site,
they
will
give
you
the
same
message.
All
the
features
are
based
in
the
context
of
an
active
project.
You
can
create
multiple
projects
in
Eijel.
To
create
a
project,
go
to
http://eijel.com/projects.
It
will
initially
show
an
empty
list.

19. Click
on
Add
Project
and
a
form
will
show
up.
Name
your
first
project
as
Urela
–
Mobile
Apps
and
Website,
and
then
submit.
After
saving,
the
newly
created
project
will
show
up
in
your
list
of
projects.
Note
that
the
project
automatically
made
you
the
Scrum
Master.
You
will
learn
later
what
it
means
to
become
a
Scrum
Master.
You
will
be
able
to
update
a
project
by
clicking
the
small
icon
after
its
name.
In
the
next
chapter,
we
will
study
more
the
details
of
a
project.

20. Project
A
Context
for
Everything
When
a
Project
is
Deleted

21. A
Context
for
Everything
All
features
belong
to
a
project
In
the
previous
chapter
we
created
our
first
project.
If
you
now
explore
the
other
pages
in
the
tool,
you
will
see
that
they
all
belong
to
a
project.
The
active
project
is
the
context
of
all
the
other
pages.
So
if
you
change
the
active
project,
the
information
in
these
pages
will
also
change.
If
you
edit
a
project,
it
will
show
you
the
following
form:
Here
you
can
set
the
project
length
and
the
sprint
length.
Both
of
these
are
in
terms
of
number
of
weeks.
• Project
Length
–
the
total
number
of
weeks
allocated
for
the
project.
This
is
from
the
start
of
the
project
to
the
production
release.
• Sprint
Length
–
the
number
of
weeks
per
sprint.
You
will
know
later
what
a
sprint
is.
Even
though
there
might
be
some
concepts
that
are
not
clear
to
you,
like
the
meaning
of
a
sprint,
you
have
achieved
something
of
great
importance.
You
have
created
your
first
project,
which
is
the
basis
of
everything
in
Eijel.

22. When
a
Project
is
Deleted
Deletion
of
projects
is
allowed
You
can
create,
edit,
and
delete
projects
in
Eijel.
But
you
have
to
understand
what
it
means
when
a
project
is
deleted.
As
the
project
is
the
basis
of
all
information
contained
in
Eijel,
when
you
delete
it,
all
the
other
information
belonging
to
it
will
be
deleted
as
well.

23. Sprints
Managing
all
the
Sprints
Updating
and
Deleting
Sprints

24. Managing
all
the
Sprints
You
can
create
all
of
the
sprints
in
advance
We
have
come
to
the
part
where
you
will
be
introduced
to
the
first
agile
concept
you
will
use
in
delivering
the
product
for
Urela
–
the
concept
of
a
sprint.
A
sprint
is
one
cycle
of
work
in
agile.
The
whole
span
of
agile
development
consists
of
multiple
sprints.
In
each
sprint,
a
small
but
complete
part
of
the
whole
product
is
being
delivered.
Think
in
terms
of
the
toy
Lego.
It
is
like
delivering
multiple
blocks
of
Lego
at
a
time,
until
all
the
blocks
were
delivered.
In
waterfall,
you
deliver
the
complete
Lego
structure
at
the
end
of
the
project.
In
agile,
you
deliver
a
few
blocks
in
every
sprint,
until
all
blocks
are
delivered
at
the
end
of
the
project.
The
typical
lengths
of
sprints
are
1,
2,
3,
or
4
weeks.
You
will
learn
more
about
the
details
of
a
sprint
later
on.
For
now,
you
will
use
a
2-­‐week
sprint
for
the
product
of
Urela.
Edit
the
project
and
set
the
project
length
and
sprint
length.

25. You
can
now
create
all
the
sprints
for
the
project.
When
you
go
to
the
Sprints
tab,
the
list
will
be
initially
empty.
Click
on
Add
Sprint
and
a
form
will
show
up.
Enter
the
sprint
name,
start
date,
and
end
date.
Your
list
will
be
similar
to
below
once
you
have
created
all
your
sprints.
There
are
six
sprints
in
total
because
the
project
length
is
3
months
(equal
to
12
weeks)
and
the
sprint
length
is
2
weeks
(12/2
=
6).

26. Updating
and
Deleting
Sprints
Update
and
deletion
of
sprints
are
allowed
You
can
update
and
delete
sprints
in
the
list.
To
update
a
sprint,
click
on
the
small
icon
after
its
name.
This
will
show
a
form
where
you
can
update
the
details
of
the
sprint.
Similarly,
you
can
delete
a
sprint.
However,
you
can
only
delete
sprints
that
have
not
yet
started.
Once
a
sprint
is
already
in
progress
or
if
it
has
already
been
completed,
it
is
no
longer
deletable.

27. Scrum
Team
Building
Your
Team
When
Members
and
Roles
Change

28. Building
Your
Team
There
are
only
three
roles
in
a
Scrum
team
We
have
now
reached
the
part
where
you
will
be
introduced
to
the
next
important
concept
in
agile
development,
the
Scrum
team.
The
Scrum
team
is
a
group
of
people
accountable
for
delivering
the
product.
There
are
three
specific
roles
in
the
team:
1. Product
Owner
–
responsible
for
the
product
features
a. Continually
re-­‐prioritizes
and
refines
the
list
of
features
b. Actively
and
regularly
interacts
with
the
team
c. Reviews
the
result
of
each
sprint
2. Scrum
Master
–
responsible
for
applying
Scrum
in
the
team
a. Educates,
coaches,
and
guides
the
team
b. Serves
the
team
and
removes
impediments
c. Supports
and
empowers
the
team
as
it
becomes
self-­‐managing
3. Development
Team
–
responsible
for
developing
the
product
a. Is
self-­‐managing
–
with
high
degree
of
autonomy
and
accountability
b. Is
cross-­‐functional
–
it
includes
all
the
skills
necessary
to
deliver
the
work
in
each
sprint
c. Is
multi-­‐learning
–
each
member
continues
to
learn
other
specialties
To
add
members
to
your
Scrum
team,
go
to
the
tab
Scrum
Team.
Initially
it
will
only
contain
you
as
the
Scrum
Master.

29. Click
on
Add
Member.
This
will
open
a
form.
Enter
the
details
of
the
member
and
click
on
Send
Invitation.
The
member
will
receive
an
email
and
he
will
be
able
to
accept
the
invitation
on
his
own
Project
list.
Once
he
has
accepted,
he
will
show
up
as
a
member
in
the
team.
After
inviting
all
the
members,
your
team
will
look
like
this:

30. When
Members
and
Roles
Change
You
can
change
roles
and
members
There
are
some
rules
that
you
need
to
know
in
managing
your
Scrum
team:
1. There
can
only
be
one
Scrum
Master
–
this
is
mandatory
and
it
defaults
to
the
creator
of
the
project.
2. There
can
only
be
one
Product
Owner
–
you
will
not
be
able
to
add
more
than
one
product
owner.
3. The
development
team
–
all
developers
will
be
under
this
role
regardless
of
skill
set.
Here
are
the
rules
for
changing
the
role
of
a
member:
1. The
Product
Owner
cannot
be
changed
to
other
roles.
2. The
Scrum
Master
cannot
be
changed
to
other
roles.
3. A
Developer
can
be
changed
to
a
Product
Owner
or
a
Scrum
Master.
4. When
the
role
of
a
Product
Owner
or
Scrum
Master
has
been
taken
away,
he
will
have
a
role
of
a
Guest.
5. A
Guest
role
is
a
read-­‐only
role
in
the
project
Here
are
the
rules
for
removing
a
member
in
a
team:
1. The
Product
Owner
cannot
be
deleted.
2. The
Scrum
Master
cannot
be
deleted.
3. When
a
developer
is
deleted,
Eijel
smartly
manages
all
relevant
data
assigned
to
him.
4. A
Guest
can
be
deleted.
With
the
rules
stated
above,
you
can
easily
manage
the
team
especially
when
new
members
join
or
old
members
leave
the
team.

31. Product
Backlog
What
Needs
to
Be
Delivered
Reorganizing
the
Priority
Assigning
Points
and
Playing
Poker
Viewing
the
Burndown
Chart

32. What
Needs
to
Be
Delivered
A
prioritized
list
of
features
I
will
now
introduce
one
of
the
most
important
concepts
in
agile
development,
the
product
backlog.
If
you
remember,
in
a
traditional
waterfall
project,
most
of
the
project
time
is
spent
in
creating
documents
that
will
serve
as
a
contract
to
which
a
product
will
be
developed
and
tested.
Participants
in
a
waterfall
project
try
to
freeze
this
document
as
much
as
possible.
It
was
aimed
to
be
unchanging
for
the
rest
of
the
project
timeline.
There
is
no
such
frozen
document
in
agile
development.
Instead,
we
collect
all
the
features
for
the
product
and
put
them
in
a
simple
list.
This
list
is
ever
changing
and
very
dynamic.
It
is
always
prioritized
–
with
the
most
important
items
on
top
and
less
important
near
the
bottom.
This
list
is
called
the
product
backlog.
It
contains
everything
that
the
business
thinks
it
needs
for
the
product.
By
design
it
supports
a
sustainable
and
continuous
development
–
as
you
can
always
add
and
remove
and
shuffle
items
in
the
list.
It
is
in
stark
contrast
to
the
frozen
document
of
waterfall.
You
will
appreciate
and
understand
it
more,
when
you
see
it
in
action.
We
will
now
create
the
product
backlog
for
Urela.
Adding
user
stories
For
a
new
project,
your
product
backlog
will
be
initially
empty.
The
whole
Scrum
team
has
capability
of
adding
user
stories
in
the
list.

33. You
can
access
it
at
the
Product
Backlog
tab.
To
add
a
story,
click
on
Add
Story
and
a
form
will
show
up.
Enter
the
title
and
category
for
the
user
story.
Categories
that
you
add
will
be
available
next
time
you
add
new
stories.
After
adding
several
use
stories,
your
Product
Backlog
will
look
like
this:

34. Reorganizing
the
Priority
You
can
easily
reorder
the
product
backlog
One
of
the
important
characteristics
of
the
product
backlog
is
that
it
is
always
prioritized.
The
most
important
features
are
always
on
top
and
the
less
important
are
near
the
bottom.
To
achieve
this,
the
list
should
be
easy
to
re-­‐arrange.
With
Eijel,
you
can
easily
reorder
the
stories
in
the
Product
backlog
by
drag-­‐
and-­‐drop.
This
feature
is
a
delightful
way
of
organizing
the
stories.
Here
is
how
the
drag-­‐and-­‐drop
action
looks
like:
The
list
automatically
saves
itself
after
the
reorder
is
done.

35. Assigning
Points
and
Playing
Poker
Points
represent
level
of
complexity
To
update
a
user
story
or
to
set
its
points,
click
on
the
icon
after
the
story’s
title.
A
form
will
show
up
after
clicking
the
icon.
Points
represent
the
level
of
complexity
of
a
user
story.
By
assigning
points
to
all
of
your
user
stories,
you
can
have
a
measure
of
the
total
points
for
the
whole
project.
This
will
help
your
team
later
on
when
predicting
how
much
you
can
complete
in
each
sprint,
using
your
previous
achieved
points.
Here
is
a
suggested
approach
for
assigning
points
to
each
of
your
story:
1. Go
through
all
of
your
user
stories
and
try
to
find
the
simplest
as
well
as
the
most
complex
story.
2. Assign
1
point
to
the
simplest
and
5
points
to
the
most
complex.

36. 3. Using
the
two
user
stories
above,
assign
points
to
all
the
other
user
stories.
4. If
you
find
a
user
story
as
vague,
unclear,
or
extremely
complex,
assign
the
points
100
to
it.
5. Repeat
the
re-­‐assignment
of
points
until
all
are
within
the
1
to
5
ranges.
Clarify
later
all
those
that
have
a
100
points
by
checking
with
the
Product
Owner
or
Scrum
Owner.
You
are
now
familiar
on
how
to
create
and
update
user
stories
for
your
product
backlog.
Assigning
points
by
playing
poker
Assigning
points
is
a
team
activity.
Try
to
include
everyone
present
in
the
development
team
when
doing
the
assignment.
One
tool
used
for
this
collaborative
work
is
playing
poker.
Here
is
how
it
works:
1. Give
each
member
of
the
team
five
cards
containing
the
following
numbers:
1,
2,
3,
5,
and
100.
100
represents
complex,
unknown,
or
ambiguous
user
stories.
2. The
Scrum
master
will
read
each
of
the
user
stories,
give
them
description
and
details
so
they
are
clear
to
all
developers
participating
in
the
playing
poker.
3. Each
developer
will
assign
a
number
to
the
user
story
and
will
place
the
card
for
that
positioned
upside
down.
4. The
Scrum
master
will
ask
everyone
to
reveal
their
number
once
all
have
placed
their
cards.
5. If
all
cards
have
the
same
value,
that
will
be
the
number
for
the
user
story.
If
there
is
a
large
deviation,
the
Scrum
master
can
ask
for
an
explanation
why
a
developer
thinks
differently
from
others.
The
developers
will
repeat
again
the
process
until
a
consensus
is
reached.
6. This
way,
all
the
user
stories
will
have
points.

37. One
common
question
is
–
how
do
you
perform
playing
poker
in
a
distributed
team?
Eijel
has
a
solution
for
this.
You
can
do
playing
poker
online
using
Eijel.
Go
to
the
Playing
Poker
link
in
Eijel
and
you
will
see
a
screen
containing
all
of
the
developers.
The
X
in
the
screen
means
that
the
developer
has
not
yet
assigned
a
number
to
the
user
story.
There
are
four
buttons
in
the
screen.
They
represent
the
following:
• Estimate
–
click
this
if
you
want
to
assign
a
number
to
the
user
story
• Refresh
–
this
will
refresh
the
page
to
show
the
latest
state
of
the
cards
• Reset
–
this
will
reset
your
current
assigned
number
to
the
user
story
• Reveal
cards
–
this
will
reveal
the
values
of
all
the
cards.
A
reveal
will
only
happen
if
all
the
cards
have
a
check
mark,
meaning,
all
have
assigned
their
numbers
When
you
click
the
Estimate
button,
a
form
will
show
up
where
you
can
assign
and
submit
the
number.

38.
The
numbers
above
are
the
complete
standard
numbers
used
for
playing
poker.
Click
Submit
Estimate
when
you
have
chosen
a
number.
After
every
estimation
the
Scrum
master
updates
the
story
with
the
points
for
it.

39. Viewing
the
Burndown
Chart
How
much
work
is
left
for
the
project?
You
will
now
be
introduced
to
one
of
the
most
important
charts
in
agile,
the
burndown
chart.
It
typically
shows
the
ideal
as
well
as
the
actual
completion
of
items.
For
a
product
burndown
chart,
it
represents
the
completion
of
points.
It
is
a
tool
for
knowing
how
the
team
performs
–
whether
they
are
delayed,
on
track,
or
ahead
of
work.
Here
is
a
sample
burndown
chart
for
Eijel:

40. Wiki
Maintaining
Living
Documents
Uploading
Images

41. Maintaining
Living
Documents
Documentation
exists
Documentation
is
important,
regardless
of
the
chosen
methodology.
But
there
is
a
big
difference
between
agile
and
waterfall
documentation
–
documents
in
agile
are
living
and
dynamic
instead
of
dead
and
static.
In
waterfall,
changes
to
the
documentation,
once
signed-­‐off,
and
once
development
has
started,
is
not
acceptable.
This
is
in
stark
contrast
with
agile
where
changes
are
welcomed
especially
if
they
bring
business
value.
To
document
in
agile,
you
will
not
use
the
tool
well
known
in
waterfall,
Word.
You
are
also
not
going
to
document
everything,
only
the
essentials.
You
will
use
a
tool
called
a
wiki.
This
format
of
documentation
has
the
following
benefits:
• Anyone
in
the
team
can
update
the
document
• The
document
is
available
online
and
can
be
accessed
anywhere,
anytime
• It
is
a
living
document
and
can
always
be
corrected
and
enhanced
Eijel
has
a
built-­‐in
wiki
to
make
your
documentation
simple
and
easy.
We
value
documentation
a
lot
such
that
we
made
all
user
stories
in
the
product
backlog
automatically
have
a
corresponding
wiki
for
it.
Each
of
these
wiki
pages
also
has
acceptance
criteria.
By
automatically
documenting
each
–
there
is
no
way
ambiguity
can
stay
on
a
user
story.
If
a
story
has
a
complex
business
rule,
all
you
have
to
do
is
put
the
information
in
its
wiki
page.
Developers
will
benefit
from
such
wiki
page.
They
can
use
the
acceptance
criteria
in
creating
the
automated
tests
in
their
code.

42. Here
is
how
a
sample
wiki
page
with
acceptance
criteria
looks
like
in
Eijel:
If
your
documentation
does
not
map
to
any
specific
user
stories,
you
can
make
a
wiki
for
it.
We
call
this
kind
of
wiki
an
article.
Go
to
the
Wiki
of
Eijel
and
you
will
see
the
second
tab
for
articles:

43. Uploading
Images
You
can
add
images
to
your
wikis
Most
of
the
time
you
will
need
to
use
images
in
your
documentation.
To
make
things
simple
and
easy
for
you,
Eijel
included
a
tool
for
uploading
images
that
you
can
use
in
your
documentation.
Go
to
the
third
tab
of
the
wiki
tool
and
you
will
see
the
place
for
uploading
images.
Initially
your
list
will
be
empty:
Click
on
New
Photo
Upload
and
a
form
will
show
up.
You
can
now
upload
a
photo.
Your
uploaded
photo
will
show
up
afterwards
in
your
list.

44. Sprint
How
Much
Work
Can
Be
Done?
Doing
the
Actual
Work
Progressing
the
Tasks
Closing
a
Sprint
Viewing
the
Burndown
Chart

45. How
Much
Work
Can
Be
Done?
The
challenge
of
estimation
One
of
the
difficult
tasks
in
waterfall
is
estimation.
Sometimes
you
would
have
to
prepare
estimates
for
work
that
spans
several
months.
Depending
on
the
project
complexity,
these
estimates
could
be
wrong
by
days
or
weeks.
Estimations
are
also
needed
for
agile
development.
But
you
will
rarely
estimate
time
allocation
for
work
that
spans
4
weeks.
The
shorter
the
span
of
time,
the
more
accurate
the
estimates
are.
One
of
the
questions
you
will
face
in
every
sprint
is
how
much
work
can
be
done?
Since
the
sprint
consist
only
of
a
few
weeks,
this
is
not
very
difficult.
Eijel
has
a
built-­‐in
tool
that
can
make
this
even
easier.
It’s
called
Capacity
Calculation
and
it
will
help
you
produce
highly
accurate
estimates.
It
is
accurate
because
it
tries
to
be
empirical
as
much
as
possible.
With
Capacity
Calculation,
you
will
be
able
to
get
accurate
answers
to
the
following
questions:
1. How
much
development
hours
will
the
team
produce
in
the
next
sprint?
2. How
much
hours
will
the
team
spend
on
meetings?
3. How
much
hours
will
the
team
spend
on
bug
fixing?

46. 4. How
much
hours
will
the
team
be
off?
You
get
the
answers
above
by
following
these
steps:
1. Go
to
Capacity
Calculation
in
Eijel
2. The
tool
will
show
each
of
the
developers
in
the
team
3. You
will
ask
each
developer
the
following
questions
a. Do
you
have
any
planned
leaves
in
the
next
sprint?
b. How
much
development
time
will
you
allocate
next
sprint?
c. How
much
bug
fixing
time
will
you
allocate
next
sprint?
d. How
much
meeting
time
will
you
allocate
next
sprint?
4. Check
the
calendar
for
any
holidays
in
the
coming
sprint.
Add
the
hours
to
the
Hours
Off
for
each
developer.
5. Enter
the
values
for
each
developer

47. 6. Once
all
the
values
are
entered
into
the
tool,
you
will
see
the
total
development
time
for
the
team.
You
know
now
that
your
team
can
allocate
315
hours
to
development
in
the
next
sprint.
You
will
now
determine
the
actual
work
that
can
be
done
for
the
315
hours.

48. Doing
the
Actual
Work
What
actual
work
can
be
done?
In
the
previous
lesson
we
were
able
to
determine
that
we
have
315
hours
allocated
for
development
in
the
next
sprint.
We
will
now
determine
what
we
can
we
can
achieve
with
that
315
hours.
It
is
time
also
to
introduce
an
important
concept
in
agile
development,
sprint
planning.
Sprint
planning
consists
of
two
parts:
1. Part
One
–
the
goal
is
to
determine
what
will
be
included
in
the
sprint.
This
is
done
by
the
Product
Owner,
with
the
help
of
the
rest
of
the
team.
2. Part
Two
–
the
goal
is
to
determine
the
number
of
stories
the
development
team
can
deliver
and
how
they
will
deliver
them.
The
development
team
does
this.
The
output
of
the
sprint
planning
is
called
the
sprint
backlog.
It
is
the
list
of
stories,
and
their
tasks,
that
must
be
completed
in
the
sprint.
Sprint
planning
is
seamless
and
very
easy
in
Eijel.
For
the
first
part
of
sprint
planning,
the
Product
Owner
adds
stories
to
the
sprint
by
following
these
steps:
1. Go
to
the
product
backlog
2. Add
a
user
story
to
the
sprint
by
clicking
its
Start
link
3. Once
the
story
has
been
started,
its
status
will
change
into
In
Progress

49. 4. Start
all
the
other
stores
needed
for
the
sprint
5. Verify
that
the
current
sprint
has
started
in
the
Sprints
tab
6. You
can
now
view
your
sprint
backlog
in
the
Sprint
Backlog
page
For
the
second
part
of
sprint
planning,
the
development
team
determines
the
actual
number
of
stories
they
can
deliver
by
following
these
steps:
1. Notice
that
each
story
takes
0
hours
to
complete.
This
is
because
they
do
not
have
any
tasks
2. To
add
tasks
to
a
user
story,
click
on
Add
Task.
A
form
will
show
up
where
you
can
enter
the
title
of
the
Task
and
its
estimate
in
hours.

50.
3.
Once
you
have
completed
adding
tasks
to
all
of
your
user
stories,
your
Sprint
Backlog
will
look
like
this:
4. You
can
easily
see
the
total
number
of
hours
your
team
will
need
to
complete
the
sprint.
The
total
hours
for
done
and
in-­‐progress
tasks
are

51. also
shown.
The
sprint
backlog
shows
that
the
team
can
achieve
this
amount
of
work
for
the
sprint.
At
this
point,
the
development
team
can
inform
the
Product
Owner
that
it
can
add
more
stories
into
the
sprint.
They
will
do
this
until
they
have
reach
a
number
where
it
matches
the
allocated
development
time.

52. Progressing
the
Tasks
Easy
drag-­‐and-­‐drop
In
the
previous
lesson
we
have
determined
the
contents
of
the
sprint
backlog.
We
will
now
look
into
the
actual
progressing
of
the
tasks.
If
you
have
observed,
we
initially
did
not
assign
tasks
to
developers.
These
tasks
will
be
assigned
in
real-­‐time.
When
they
are
about
to
be
done.
This
is
a
pull
model
as
compared
to
the
push
model
of
waterfall.
The
developers
assign
the
tasks
to
themselves.
This
shows
the
spirit
of
collective
ownership
in
an
agile
team.
Assigning
a
Task
To
assign
or
edit
a
task,
click
the
icon
after
the
title.
This
will
show
a
form.
Every
tasks
has
a
status:
1. Todo
–
the
task
has
not
yet
been
started
and
has
not
yet
been
assigned
2. In
Progress
–
the
task
is
being
worked
by
a
developer
3. Done
–
the
task
has
been
completed
by
a
developer

53. To
move
a
task
from
one
status
to
another,
just
drag
and
drop
the
item.
Once
your
team
has
started
working
on
the
tasks,
the
sprint
backlog
will
be
similar
to
this:
You
can
easily
see
the
number
of
hours
for
Todo,
In
Progress,
and
Done.

54. Closing
a
Sprint
Closed
sprints
can
be
viewed
Your
development
team
will
give
its
best
in
completing
all
user
stories
in
the
sprint.
Regardless
if
all
stories
were
completed,
at
the
last
day
of
the
sprint,
you
would
have
to
close
the
sprint.
This
follows
the
time-­‐boxed
nature
of
activities
in
agile
development.
When
your
team
has
completed
all
the
tasks
for
the
user
stories,
the
stories
will
show
up
as
Done
in
the
Product
Backlog.
You
can
end
your
Sprint
by
clicking
End
at
the
Sprints
tab.

55. After
clicking
End,
the
Sprint
will
be
marked
as
Done.
You
will
still
be
able
to
view
previous
Sprints
by
clicking
View.
This
way
you
can
know
what
tasks
were
included
and
who
worked
on
the
tasks
of
previous
sprints.

56. Viewing
the
Burndown
Chart
How
much
work
left
for
the
sprint
At
any
time
during
the
sprint,
you
will
be
able
to
view
the
burndown
chart
for
the
sprint.
This
chart
represents
the
remaining
hours
left
to
be
completed
for
the
sprint.
It
can
also
show
you
how
your
team
is
performing
against
the
ideal
burndown.

57. Bug
Tracker
Managing
Project
Defects

58. Managing
Project
Defects
Defects
are
normal
Defects
can
occur
in
any
project,
regardless
of
the
methodology
followed
during
the
development.
We
consider
them
as
normal
and
accept
them
as
part
of
life.
For
this
reason,
we
gave
our
best
in
creating
what
we
believe
is
the
currently
best
defect
tracking
tool
in
existence.
And
this
tool
comes
as
part
of
Eijel.
Introducing
the
Eijel
Bug
Tracker.
At
one
glance,
you
can
easily
know
the
state
of
your
project
with
regards
to
defects.
You
know
right
away
the
following
important
statistics:
• Count
of
Open
defects
• Count
of
Show
Stopper
open
defects
• Count
of
High
priority
open
defects
• Count
of
Medium
priority
open
defects
• Count
of
Low
priority
open
defects
• Count
of
Unassigned
defects
• Count
of
Fixed
defects
• Count
of
Ready
for
Retest
defects
• Total
number
of
defects
for
the
project

59. The
Eijel
Bug
Tracker
is
a
grand
example
of
opinionated
software.
It
will
not
allow
you
to
sort
the
columns,
as
it
sorts
itself
on
its
own.
It
follows
the
following
rules
1. The
list
is
first
sorted
based
on
importance
–
with
the
highest
severity
on
top.
It
follows
the
following
order:
Show
Stopper,
High,
Medium,
and
Low.
2. The
list
is
sorted
afterwards
based
on
progress
–
with
the
newest
on
top.
It
follows
the
following
order:
New,
Assigned,
In
Progress,
Fixed,
Ready
for
Retest.
3. Closed
issues
are
always
at
the
bottom.
Once
you
have
experienced
this
smart
auto
sorting,
you
will
never
come
back
to
other
defect
tracking
tools.
The
bug
tracker
has
also
one
of
the
best
search
functionality
among
tools
–
as
most
of
the
time
–
developers
are
searching
for
specific
issues
and
do
not
want
to
see
the
whole
list.
Often
they
just
want
to
see
the
issues
that
are
assigned
to
them
or
the
issues
they
have
worked
on.
By
clicking
on
the
Search
Icon,
the
search
functionality
will
show
up:
With
this
feature,
you
will
be
able
to
filter
on
any
of
the
columns
in
the
bug
list.
The
best
features
of
the
Bug
Tracker
are
not
limited
only
on
the
list
and
on
the
search
–
when
you
click
the
title
of
the
defect,
it
will
bring
you
to
a
wiki
page
exclusive
for
that
defect.
In
our
experience,
the
true
value
of
a
defect
tracker
comes
from
user
interactions
that
happen
within
the
defect.
This
means
communication
and
clarification
by
means
of
comments
and
attachments,
all
fully
supported
within
the
tool.

60. When
you
click
on
one
of
the
issues,
you
will
see
its
wiki.
The
developers
involved
in
testing
and
fixing
can
easily
attach
files
and
create
threaded
conversations
in
this
wiki
page.

61. Software
Engineering
Serve
the
Developers
The
Value
of
Quality
Code

62. Serve
the
Developers
A
servant
leader
is
not
a
boss
In
agile
development,
much
emphasis
is
placed
on
empowering
the
development
team.
Because
at
the
end,
they
are
the
one
really
creating
the
product.
The
product
will
be
a
creation
of
the
development
team.
They
deserve
this
credit.
The
Scrum
Master
helps
the
team
achieve
their
best
by
removing
any
impediments
that
can
block
them.
Eijel
helps
in
this
goal
by
providing
within
the
tool
a
means
for
managing
impediments.
You
will
be
able
to
add,
edit,
and
set
the
status
of
each
impediment.
Anyone
in
the
Scrum
team
can
add
impediments.
Notice
that
they
are
not
assigned
to
a
name,
as
it
is
implied
that
the
Scrum
Master
will
handle
the
impediments,
with
help
from
within
and
outside
the
team.

63. The
Value
of
Quality
Code
Reduce
undone
work
Depending
on
the
maturity
and
skills
of
the
developers,
they
would
have
some
undone
work.
Remember
that
the
goal
of
every
sprint
is
to
product
a
complete
set
of
features.
These
features
should
be
potentially
shippable
to
production.
However,
there
are
times
when
developers
can’t
follow
all
the
requirements
to
produce
the
level
of
quality
set
by
the
team.
These
things
are
called
undone
work.
Eijel
has
the
feature
for
managing
undone
work.
Notice
that
the
items
are
not
assigned
to
any
specific
developer.
This
is
because
it
is
implied
that
it
is
everybody’s
business
to
make
sure
his
or
her
quality
of
work
does
not
include
any
undone
work.
This
is
in
the
spirit
of
continuous
improvement.

64. Conclusion
A
Promise
Kept
Succeeding
in
Your
Projects

65. A
Promise
Kept
You
can
only
master
the
things
you
actually
do
I
have
given
you
four
promises
at
the
start
of
the
book.
I
promised
you
that:
1. You
will
know
how
to
do
agile.
2. You
will
know
how
to
achieve
complete
agility.
3. You
will
know
how
to
master
agile.
4. You
will
succeed
in
all
of
the
above
if
you
give
the
effort
in
actually
doing
At
this
part
of
the
book,
you
know
how
to
do
agile.
You
know
how
to
actually
do
it
using
Eijel.
You
have
a
mental
context,
an
anchor
to
reality
when
you
think
of
the
following
words:
• Product
Backlog
• Sprint
• Scrum
Team
• Sprint
Planning
• Sprint
Backlog
• Impediments
• Undone
Work
• Burndown
Chart
• And
other
agile
concepts
You
can
only
master
the
things
that
you
actually
do.
By
giving
effort
in
the
part
of
actually
doing,
you
will
gain
mastery.

66. Succeeding
in
Your
Projects
Create
your
free
Eijel
account
I
created
Eijel
with
the
goal
of
creating
the
simplest
tool
that
manages
agile
projects
from
vision
to
product
release.
I
now
invite
you
to
give
Eijel
a
try
in
actually
doing
your
agile
projects.
Eijel
is
free.
By
using
the
principles
and
practices
you
learned
in
this
book,
and
by
actually
doing
agile
with
the
help
of
Eijel,
you
will
succeed
in
your
software
development
projects.
Thank
you
for
taking
this
learning
journey
with
me.
If
you
would
like
to
learn
more,
you
can
visit
my
blog
at:
http://completeagility.com
You
can
see
my
contact
info
at:
http://eijel.com/contact
Feel
free
to
add
me
in
LinkedIn
at:
http://sg.linkedin.com/in/dondonvizcayno