This document outlines an Agile planning and estimating workshop presented by Joshua Partogi. The workshop covers Scrum concepts like timeboxing, product backlog creation and ordering, estimating work in story points, sprint planning, and monitoring progress via burn down charts and velocity. Participants work through exercises to practice these techniques in planning and estimating the work for a mobile tourism app project over multiple sprints and releases.

1. Scrum Planning and Estimating Workshop
Joshua Partogi
@jpartogi
Agile Korea Conference 2012
Scrum.org - Improving the Profession of Software Development

2. Who Am I? 안녕
• Professional Scrum Trainer through Scrum.org
• Scrum Indonesia 인도네시아 community founder
• K-pop 가요 and Korean drama 한국드라마 avid and Korean food lover
Scrum.org - Improving the Profession of Software Development

3. The rule of the game
5
• Every events in Scrum have timebox mins
• We are going to do many discussions and exercises in groups
• Every discussions and exercises will have timebox
This shows the timebox
Scrum.org - Improving the Profession of Software Development

4. Team Forming and Discussion
5
Form a group of 5 and discuss these questions mins
• Give your team a name
Scrum.org - Improving the Profession of Software Development

5. How do we answer these questions?
• When is the project is going to finish?
• How much is the project going to co$t?
Scrum.org - Improving the Profession of Software Development

6. Today we are going to learn about estimating and
planning in Scrum
cises
Wit h joyful exer
y
along the wa
Scrum.org - Improving the Profession of Software Development

7. Group Estimation
In Scrum, estimation is only done by group of people who will be committing to
do the work.
Everyb
e o
eads ar own o dy have thei
Two h e p
solid p inions of how
r
than on
better roduct
should a
By getting many opinions from be
many different people we can
have many alternatives that can
be systematically evaluated
ore
People are m ork
committe d with the w
by
that are estimated
themselves
Scrum.org - Improving the Profession of Software Development

8. The Myth
With more analysis and
effort, estimates get
significantly more accurate.
Scrum.org - Improving the Profession of Software Development

9. Estimation is often Expensive
Accuracy'
Effort'or'Time'
Scrum.org - Improving the Profession of Software Development

10. The Basic Truths
• It doesn’t matter how long you do the planning and estimate, if you don’t have all
the skills required you may still come up with a bad plan.
• The best way to predict the future is not to come up with detailed analysis but to
invent it and inspect the outcome.
• It is important to have cross-functional team to come up with good estimate
otherwise you have a dysfunctional team.
Scrum.org - Improving the Profession of Software Development

11. Levels of Planning in Scrum
• Sprint Planning is just first step
• Plan constantly, not just in the beginning
• Planning is an activity, not a document
• Recognize, embrace, and support Release Sprint Daily
Planning Planning Planning
change rather than trying to control it
Scrum.org - Improving the Profession of Software Development

12. Visit Korea Mobile Apps
To support the Visit Korea program, the Korea Tourism Organisation want to make
a location based mobile apps that will help tourists find notable places in Korea.
• Tourist should be able to search and make an online • The system should handle internationalization as many
both from browser and mobile app booking for all types tourists from all over the world will be using this
of accomodation (i.e Hotel, Budget, Homestay) in Korea. application.
• Tourist should be able to rate and give a comment for • The web application should be viewable on major
the accomodation they have stayed in. browsers.
• Tourist should be able to search other members who • The apps should support mobile web and native mobile
offers their service as tourist guide. apps as well as desktop web.
• Tourist should be able to give an online financial reward • The system should be scalable for up to 100,000 users
and give a recommendation for these tourist guides. and available 24/7.
• Tourist should be able to find nearby notable restaurants • The system should be secure as there will be some
and places to visit from their mobile phone. transaction involved.
• Tourist should be able to rate and give a comment for
the restaurants and places they have visited.
Scrum.org - Improving the Profession of Software Development

13. The Plan
• The KTO virtually has unlimited funding for this project but would prefer something
is released as soon as possible so that users can use it and give feedback about the
apps.
• Today is the September 1st. KTO plan to have the first release on December 1st
right before Christmas.
• The first release should be the minimum viable product with core functionalities and
should at least support one mobile platform.
• If the core functionalities is not available, user will not use the product and the
project will be a loss.
• The second release is planned for March 1st should at least support another mobile
platform and have more functionalities.
Scrum.org - Improving the Profession of Software Development

14. The Release Planning Exercise
Scrum.org - Improving the Profession of Software Development

15. Creating the Product Backlog for December 1st Release
15
• Create a Product Backlog for December 1st Release ( 3 Sprints ) mins
• Just make sure you have enough work until December 1st, you don’t
have to create the Product Backlog for the whole product.
• Create a card for each Product Backlog Item / work item
• Do not strive for perfection, just the best you can do
Scrum.org - Improving the Profession of Software Development

16. Product Backlog Ordering 순서
• A Product Backlog layout a roadmap for the product so that everyone can see
the vision for the product itself.
1st Quarter 2nd Quarter 2nd Half-year The future
1st Sprint
If we still
have money
and
everything is
2nd & 3rd Sprint
going well
Scrum.org - Improving the Profession of Software Development

17. Ordering 순서 the Product Backlog
15
• Order the Product Backlog so that everyone can see what Product Backlog mins
Item will be done first and what will be done last.
• Put the relative value number on each card. Assume that you will use the
number 1-500 No two PBI can have the same value number.
• The system will be unusable if the non-functionality requirements are not
fulfilled.
• New PBI may emerge.
1 10 20 30 40 50 100 500
2 21 41
Scrum.org - Improving the Profession of Software Development

18. Estimating Product Backlog Items with Points
• Very common way to estimate work • Points are additive
• Based on size and complexity, not • Based on historical reality
duration or man hours • Easy to use and understand
• Unitless and numerically relative
• Different for each team of estimators
Scrum.org - Improving the Profession of Software Development

19. Estimating with Points
∞ : not feasible for
8 ? 8 the time being
? : still unclear
Product Backlog 0 : it is already
Item supported by the
8 system
4
2
Scrum.org - Improving the Profession of Software Development

20. Estimating 평가 the size of Product Backlog Item
15
• We are going to play Planning Poker cards. The number describe the size mins
or effort (not man hours) to implement the PBI.
• Select the PBI that have a medium relative size and assign it a 4.
• Put the PBI that are relatively easier on the left hand side and the PBI that
are relatively more difficult on the right hand side of the medium PBI.
• Now estimate the PBI as a group.
• Each estimator selects a card that’s his or her estimate.
• Cards are turned over so all can see them (synchronously).
• Don’t broadcast opinion before the cards are turned over.
• Re-estimate until estimates converge.
Scrum.org - Improving the Profession of Software Development

21. The Sprint Planning Exercise
Scrum.org - Improving the Profession of Software Development

22. Sprint Planning
• In Scrum, Sprint Planning is divided into two parts.
• In the first part, the purpose is to discuss what to make. The Sprint Goal is
crafted.
• In the second part, the purpose is to discuss how to implement the selected
Product Backlog Item from the first part. The output is the Sprint Backlog
Scrum.org - Improving the Profession of Software Development

23. Sprint Planning Part 1
15
• There are three 1 month Sprints until December 1st. mins
• Your team has worked together before and based on historical data your
team is only able to deliver 16 points of work in one month Sprint.
• Based on the ordered Product Backlog, select the Product Backlog Items
for the 1st Sprint.
• If the PBIs are too large, you may need to decompose the PBIs into
several smaller items so that it fits in one Sprint.
• Tear apart the cards that are no longer used to prevent confusion.
• From the selected Product Backlog Items, define the Sprint goal
Scrum.org - Improving the Profession of Software Development

24. Sprint Planning Part 2
15
• Now that we have selected the PBIs for the first Sprint we are going to mins
define the works to implement the PBIs
• For each PBIs, define the tasks needed to be done.
• Each tasks may not exceed more than one day to accomplish.
• Tasks may include several functions such as design, programming, quality
control, documentation
• Write each tasks on one sticky.
• Write the number of hours needed for each tasks.
Scrum.org - Improving the Profession of Software Development

25. Scrum Board
Put these Sprint Backlog to be visible for everyone to see so that everyone knows
what needs to be done during the Sprint
PBI TODO In Progress Done
Scrum.org - Improving the Profession of Software Development

26. Monitoring Sprint Progress
• Scrum suggests that the team
150
has a tool to monitor progress
towards the end of the Sprint
112.5
• Sprint Burndown chart is one of
75
the tool
• The metric can be number of
37.5
remaining hours, remaining tasks
or remaining points
0
• This is updated daily usually after
1 2 3 4 5 6 7 8 9 10
Daily Scrum Meeting
Scrum.org - Improving the Profession of Software Development

27. Velocity
• Velocity 속도 is the capacity 용적 of how much the team can do in one Sprint.
• Usually an accumulation or addition of points “done” PBIs in one Sprint.
Scrum.org - Improving the Profession of Software Development

28. Release Planning Rule of Thumb
1. An accurate Release Plan requires an ordered an estimated Product Backlog
2. An accurate Release Plan requires a known Velocity
Scrum.org - Improving the Profession of Software Development

29. From here we can be confident to tell the
customer when a project will be finished and go
for a fix bid project
Scrum.org - Improving the Profession of Software Development

30. Thank You
감사합니다
@jpartogi
Scrum.org - Improving the Profession of Software Development

31. Learn more about Scrum at
Professional Scrum Master Training
Visit http://scrumway.asia
Scrum.org - Improving the Profession of Software Development