Agile planning & estimating joshua partogi

Scrum Planning and Estimating Workshop
Joshua Partogi
@jpartogi
Agile Korea Conference 2012

Scrum.org - Improving the Profession of Software Development

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


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


Team Forming and Discussion

5
Form a group of 5 and discuss these questions mins

• Give your team a name


How do we answer these questions?
• When is the project is going to ﬁnish?
• How much is the project going to co$t?


Today we are going to learn about estimating and
planning in Scrum
cises
Wit h joyful exer
y
along the wa


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

The Myth

With more analysis and
effort, estimates get
signiﬁcantly more accurate.


Estimation is often Expensive

Accuracy'

Eﬀort'or'Time'


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.


Levels of Planning in Scrum
• Sprint Planning is just ﬁrst 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


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.


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 ﬁrst release on December 1st
right before Christmas.
• The ﬁrst 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.

The Release Planning Exercise


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


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


Ordering 순서 the Product Backlog

15
• Order the Product Backlog so that everyone can see what Product Backlog mins

Item will be done ﬁrst 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
fulﬁlled.
• New PBI may emerge.

1 10 20 30 40 50 100 500

2 21 41


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
• Diﬀerent for each team of estimators


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


Estimating 평가 the size of Product Backlog Item

15
• We are going to play Planning Poker cards. The number describe the size mins

or eﬀort (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 diﬃcult 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.


The Sprint Planning Exercise


Sprint Planning
• In Scrum, Sprint Planning is divided into two parts.
• In the ﬁrst 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 ﬁrst part. The output is the Sprint Backlog


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 ﬁts in one Sprint.
• Tear apart the cards that are no longer used to prevent confusion.
• From the selected Product Backlog Items, deﬁne the Sprint goal


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 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


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


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.


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


From here we can be confident to tell the
customer when a project will be finished and go
for a fix bid project


Thank You
감사합니다
@jpartogi


Learn more about Scrum at
Professional Scrum Master Training
Visit http://scrumway.asia


Agile planning & estimating joshua partogi

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Agile planning & estimating joshua partogi

Similaire à Agile planning & estimating joshua partogi (20)

Plus de Sangcheol Hwang

Plus de Sangcheol Hwang (8)

Dernier

Dernier (20)

Agile planning & estimating joshua partogi