Agile planning & estimating joshua partogi

Scrum.org - Improving the Profession of Software Development

Joshua Partogi

Scrum Planning and Estimating Workshop

Agile Korea Conference 2012

@jpartogi


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

Who Am I? 안녕


5mins

The rule of the game

• Every events in Scrum have timebox• We are going to do many discussions and exercises in groups• Every discussions and exercises will have timebox

This shows the timebox


5mins

Team Forming and Discussion

Form a group of 5 and discuss these questions• Give your team a name


• When is the project is going to finish?• How much is the project going to co$t?

How do we answer these questions?


Today we are going to learn about estimating and planning in Scrum

With joyful exercises

along the way


In Scrum, estimation is only done by group of people who will be committing to do the work.

Group Estimation

Two heads are

better than one

By getting many opinions from many different people we can

have many alternatives that can be systematically evaluated

Everybody have their own opinions of how a

solid product should be

People are more

committed with the work

that are estimated by

themselves


With more analysis and

effort, estimates get

significantly more accurate.

The Myth


Accuracy'

Effort'or'Time'

Estimation is often Expensive


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

The Basic Truths


Levels of Planning in Scrum

Release Planning

Sprint Planning

Daily Planning

• Sprint Planning is just first step• Plan constantly, not just in the beginning• Planning is an activity, not a document• Recognize, embrace, and support

change rather than trying to control it


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.

Visit Korea Mobile Apps

• Tourist should be able to search and make an online both from browser and mobile app booking for all types of accomodation (i.e Hotel, Budget, Homestay) in Korea.

• Tourist should be able to rate and give a comment for the accomodation they have stayed in.

• Tourist should be able to search other members who offers their service as tourist guide.

• Tourist should be able to give an online financial reward and give a recommendation for these tourist guides.

• Tourist should be able to find nearby notable restaurants and places to visit from their mobile phone.

• Tourist should be able to rate and give a comment for the restaurants and places they have visited.

• The system should handle internationalization as many tourists from all over the world will be using this application.

• The web application should be viewable on major browsers.

• The apps should support mobile web and native mobile apps as well as desktop web.

• The system should be scalable for up to 100,000 users and available 24/7.

• The system should be secure as there will be some transaction involved.


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

The Plan


The Release Planning Exercise


15mins

Creating the Product Backlog for December 1st Release

• Create a Product Backlog for December 1st Release ( 3 Sprints )• 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


• A Product Backlog layout a roadmap for the product so that everyone can see the vision for the product itself.

Product Backlog Ordering 순서

If we still have money

and everything is going well

1st Quarter 2nd Quarter 2nd Half-year The future

1st S

prin

t2n

d &

3rd

Sprin

t


15mins

Ordering 순서 the Product Backlog

• Order the Product Backlog so that everyone can see what Product Backlog 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


Estimating Product Backlog Items with Points• Very common way to estimate work• Based on size and complexity, not

duration or man hours• Unitless and numerically relative• Different for each team of estimators

• Points are additive• Based on historical reality• Easy to use and understand


Estimating with Points

Product Backlog Item

4

2

?8

8

8∞ : not feasible for the time being? : still unclear0 : it is already supported by the system


15mins

Estimating 평가 the size of Product Backlog Item

• We are going to play Planning Poker cards. The number describe the size 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.


The Sprint Planning Exercise


• 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

Sprint Planning


15mins

Sprint Planning Part 1

• There are three 1 month Sprints until December 1st.• 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


15mins

Sprint Planning Part 2

• Now that we have selected the PBIs for the first Sprint we are going to 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.


Put these Sprint Backlog to be visible for everyone to see so that everyone knows what needs to be done during the Sprint

Scrum Board

PBI TODO In Progress Done


Monitoring Sprint Progress

0

37.5

75

112.5

150

1 2 3 4 5 6 7 8 9 10

• Scrum suggests that the team has a tool to monitor progress towards the end of the Sprint

• Sprint Burndown chart is one of the tool

• The metric can be number of remaining hours, remaining tasks or remaining points

• This is updated daily usually after Daily Scrum Meeting


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

Velocity


1. An accurate Release Plan requires an ordered an estimated Product Backlog2. An accurate Release Plan requires a known Velocity

Release Planning Rule of Thumb


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

Technology

Transcript of Agile planning & estimating joshua partogi