Agile planning & estimating joshua partogi

  • 762 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
762
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
21
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Scrum Planning and Estimating Workshop Joshua Partogi @jpartogi Agile Korea Conference 2012Scrum.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 loverScrum.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 timeboxScrum.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 nameScrum.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 waScrum.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 themselvesScrum.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 EffortorTimeScrum.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 itScrum.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 ExerciseScrum.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 doScrum.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 wellScrum.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 41Scrum.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 estimatorsScrum.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 2Scrum.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 ExerciseScrum.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 BacklogScrum.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 goalScrum.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 DoneScrum.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 MeetingScrum.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 VelocityScrum.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 projectScrum.org - Improving the Profession of Software Development
  • 30. Thank You 감사합니다 @jpartogiScrum.org - Improving the Profession of Software Development
  • 31. Learn more about Scrum at Professional Scrum Master Training Visit http://scrumway.asiaScrum.org - Improving the Profession of Software Development