A compilation of the absolute basics for those who want to know about Agile Methodology with some insights on Scrum. The idea is to give enough to fuel the curiosity to learn more. It might not interest one of he / she is an Agile guru but may I ask for your review / comments / suggestions. I'd love to hear from you all...

1. Basics of Agile & Scrum
Mazhar Khan

2. Agile Manifesto

3. Agile Myth #1
Agile = No
documentation
“Working software over
comprehensive documentation”
is often misunderstood with
no documentation at all. But
how could agile Frameworks
like Scrum survive in highly
regulated environments like
the medical or financial
industry if this were to be true.
For sure there is
documentation, but we don’t
waste time on documents that
deliver no value to the project.

4. Agile Myth #2
Agile = Anarchy
The biggest fear of any
manager is to lose control
over their agile teams. Self
organization is often
interpreted as anarchy.
Management is required to
define clear visions and
goals and the constraints of a
project

5. Agile Myth #3
Agile = Faster
It isn't faster just because it’s
called a Sprint!
Writing quality software is
serious business and takes
time. One cannot guarantee
that doing Agile would mean
delivering faster. However
one could guarantee having
delivered much higher value
in a comparable time.

6. Agile Myth #4
Agile = Silver Bullet
Agile is not the only solution
know to mankind! However
strong the case of merits and
values can be put forth, one
can’t deny that several
successful products have
been delivered using
waterfall or other
methodologies. Its not a one
size fits all approach .
It’s all about people after
all…

7. Agile Myth #5
Agile = Simple
Switch
It’s more got to do with
“being” Agile and not
“doing” Agile. While a
simple 2-day course might
arm you with the basic
concepts it might take long
to imbibe the principles that
Agile methods are based on

8. Agile Myth #6
Agile = Easy
To be able to deliver a
potentially shippable
product every 2-4 weeks is
not easy. Not many
development methodologies
can even attempt this.
Considering Agile to be easy
would be detrimental.
However, once the team is
Agile-mature, it does run
like a well oiled engine with
minimum interference.

9. Agile Myth #7
Agile = Software
Development
Often the agile journey starts
with software development,
but it should not stop there.
To have an agile software
development team in an non-
agile environment is like
planting a tree in the desert -
it won’t survive. The whole
company culture has to
change, everybody needs to
adhere to the agile principles
like lean thinking.

10. Agility overcomes…
 Communication Problems
 The delivered solution isn’t really what the
business wanted
 Unused Features
 Building the right thing – the business changing
their mind
 Delayed or late Return on Investment (ROI)
 Over-engineering (‘Gold plating’)

11. SCRUM Basics

12. Scrum Roles

13. Scrum Shot!

14. Scrum Requirements

15. Scrum Requirements
 User Story - A story is a self-contained unit of work agreed upon
by the developers and the stakeholders. Stories are the heart of
Scrum, and the building blocks of your sprint. E.g. As a
salesperson, I'd like to set my password, so I can log into the system
 Theme – A group of related stories contributing to a common goal
or are related in some obvious way, such as all focusing on a
single customer. However, while some stories in a theme may be
dependent on one another, they do not need to encapsulate a
specific work flow or be delivered together
 Epic - Epics resemble themes in the sense that they are made up of
multiple stories. They may also resemble stories in the sense that,
at first, many appear to simply be a "big story." As opposed to
themes, however, these stories often comprise a complete work
flow for a user and their business value isn't realized until the
entire epic is complete

16. Scrum Artifacts

17. Scrum Artifacts
 Product Backlog - Prioritized features list, containing
short descriptions of all functionality desired in the
product typically written by the Product Owner and the
Scrum Team
 Sprint Backlog – List of user stories identified during a
Sprint Planning meeting by the Scrum team to be
completed in a Sprint
 Potentially Shippable Product - A potentially shippable
product is one that is ready for distribution to anyone in
the company for review or even to any external
stakeholder. Adhering to a list of “done” criteria ensures
that the sprint product is truly shippable

18. Scrum Ceremonies

19. Sprint
Planning
Meeting
 WHEN – At the start of each
Sprint, usually day long
 WHO – Product Owner, Scrum
Master and the entire Scrum
team. Outside stakeholders may
attend by invitation of the team
 WHAT
 Product Owner - Describes the
highest priority features to the
team
 Team – Ask questions, refine the
user stories, commit to a set of
user stories that would be
delivered in the sprint and do
task break down
 Scrum Master – Facilitates,
servant-leader
 Outcome
 Sprint goal
 Sprint Backlog

20. Daily Standup meeting

21. Daily Standup
meeting
 WHEN – Each day of the Sprint
at a fixed place at a fixed time
(time-boxed to 15 minutes)
 WHO – Product Owner, Scrum
Master and the entire Scrum
team
 WHAT – Each participant
answers the following
questions
 What did I do yesterday?
 What will I do today?
 Are there any impediments in
my way?
 Outcome
 Update the story board /
progress
 Team members make
commitments to each other
 Impediments list modified

22. Sprint Review / Demo

23. Sprint Review
/ Demo
 WHEN – At the end of each
Sprint (Four-hour time limit)
 WHO – Product Owner,
Scrum Master, the entire
Scrum team, management
and stakeholders
 WHAT –
 Demonstrate working
software
 No PowerPoint
presentations
 Presented as a natural result
of the sprint vis-à-vis the set
Sprint Goal
 Outcome
 Record feedback

24. Sprint Retrospective

25. Sprint
Retrospective
 WHEN – At the end of each
Sprint (Three-hour time
limit)
 WHO – Product Owner,
Scrum Master, the entire
Scrum team
 WHAT –
 Reflect on the Sprint metrics
 Discuss what went good
 Discuss what needs to be
improved
 Discuss continuous
improvements
 Outcome
 Record feedback and create
actionable items for
improvements

26. Metrics – Sprint Burn
down
Graphical representation of work left to do versus time

27. Metrics – Velocity Trend
Velocity is how much product backlog effort a team
can handle in one sprint

28. References & Vote of Thanks!
 Marc Löffler - 7 Agile Myths
 DSDM Handbook
 Jeremy Jarrell - Stories versus Themes versus
Epics
 Wikipedia – Scrum (software development)
 Scrum Alliance
 ! - None of the images have been created and have been simply used after an
preliminary assessment of their copyright. Kindly contact the author in case of any
discrepancy and the image will be removed

29. Be Agile, not just Do Agile
Thank you!