This document provides an overview of Scrum, an agile framework for project management. Scrum utilizes short development cycles called sprints to develop working software incrementally. It focuses on user stories, prioritized backlogs, daily stand-up meetings, and sprint retrospectives to facilitate collaboration between roles like Product Owners, Scrum Masters, and team members. The goal is to continually deliver working features to customers through an iterative process of planning, development, and improvement.

1. SCRUM!
For Agile Product Development
by: Anton Rifco <anton.rifco@gmail.com>
Friday, 7 June, 13

2. Friday, 7 June, 13

3. Why Scrum?
Because good product is what we really want. And, Great design
and thick documentation is NOT the product.
Because we don’t want to treat our documentation work as J.R.R.
Tolkien treat his “The Hobbit” script.
Our master piece is the working product
Friday, 7 June, 13

4. Friday, 7 June, 13

5. How to Scrum?
In Scrum, features are written in the perspective of end users.
It’s known as User Stories.
The collections of User Stories are called Product Backlog (or,
Wish List)
And it is the communication medium between business people
and the development team
The objective of the Software development activity is simply to
fulfill that Wish List into working application.
Friday, 7 June, 13

6. Roles in Scrum
Product Owner, confirms that the Product Backlog matches
the requirement.
Scrum Master, make sure the project is progressing smoothly
and facilitate the team members to finish their tasks. He is also
the one that assigns User stories to team members.
Team Member,
Developers: realize and develop the assigned user stories.
Testers: plan and execute the test strategy for user stories.
Friday, 7 June, 13

7. Product Owner Customers
Team MembersGandalf :)
Friday, 7 June, 13

8. Release Planning Process (1)
Identifies User stories from the Customer requirement, in the
following format:
List of User stories is called Product Backlog.
Friday, 7 June, 13

9. Release Planning Process (2)
Identify User stories (from Product Backlog) that will be
included in a particular release.
Those chosen stories are called Release Backlog.
Friday, 7 June, 13

10. Release Planning Process (3)
Prioritize chosen User stories, break down into tasks and
estimate the work to be done for each task.
Tasks are estimated into the following choices:
See... It’s Fibonacci! (because human tends to estimate better if
there’s bigger gap for bigger denomination)
•1 hour task
•2 hours task
•3 hours task
•5 hours task
•8 hours task
•2 days task
•3 days task
•5 days task
Friday, 7 June, 13

11. Release Planning Process (4)
•After we have the Release Backlog, separate the tasks into few
chunks (2 or 3) to make few sprints.
•Each sprint is a short duration milestone to get into a ship
ready state, e.g. every one week sprint.
•Each sprint contains homogenous or interdependent tasks.
Friday, 7 June, 13

12. Release Planning Process (5)
•Note: Late in Sprint is an indication that the product release will
not be on schedule.
•Therefore, it’s important to track Sprint. Burndown chart
provides the day-by-day measure of the amount of works that
remain in a given sprint.
Friday, 7 June, 13

13. Release Planning Process (6)
•Using the chart, we can measure the Burndown Velocity to keep
track of the sprint.
•It’s the average productivity each day. From this velocity, team
can decide whether or not to pace up (adjust) the development
efforts in order to meet the deadline.
Friday, 7 June, 13

14. Release Planning Process (7)
•Each completing a Sprint, there will be a Sprint Retrospective
meeting.
•It’s to analyze what went right and what went wrong and what can
be improved for the next sprint.
•Discussion should be objective (not subjective), meaning that it
should focus on the tasks rather than complaining about the
person that worked on them.
Friday, 7 June, 13

15. Release Planning Process (7)
•Project is considered done, after all Product Backlog User stories
are finished through few Sprint delivery.
•Note: In scrum, it’s important to define the Definition of Done
(DoD) within a team. It can be task fully developed, or fully
developed and tested, or fully developed and tested and
deployed. It’s up to your team, mate!
Friday, 7 June, 13

16. Friday, 7 June, 13

17. Daily Scrum
•A daily Stand-up meeting (usually in the morning) to have
information flows freely within team member.
•Each team member will quickly list all the items that have been
done since the last meeting and describe any obstacle in their
way (it’s to allow discussion to tackle the obstacle)
•It’s not mandatory to explain what someone will do until the
next Daily stand-up, although it’s commonly used.
Friday, 7 June, 13

18. and the
journey
begins.
Friday, 7 June, 13

19. Good References
The Elements of Scrum, a book by Chris Sims & Hillary Louse
Johnson
The Scrum Framework in 30 Seconds, an article in http://
www.scrumalliance.org/learn_about_scrum
Intro to Agile Scrum in Under 10 Minutes, a video in http://
www.youtube.com/watch?v=XU0llRltyFM
Friday, 7 June, 13