Agile Estimation & Planning: Planning Poker

Transcription

1 Agile Estimation & Planning: Planning Poker Carlos O. Canedo A. Certified Scrum Developer Certified Scrum Master

2 Agenda Estimations in the Software Industry Why is so complex make estimations? Boehm s uncertain cone Relative Estimation Story points Planning Poker Preparing the meeting The meeting Variations Example Advantages and disadvantages

3 Agenda Velocity Release Planning Questions & Answers

4 Estimations in the Software Industry Estimation is one of the harder parts of a software project. Some data: Nearly ⅔ of projects significantly overrun their cost estimates.

5 Estimating

6 Why is so complex make estimations? Failed to do right estimation and the estimation was wrong because of in-experience The requirement was not clear There were hidden dependencies which were not visible upfront New technology was implemented so it took more time than what we thought Somebody was not available to answer questions Didn t have the right skills to do the work so essentially it took more time 6

7 Why is so complicate estimate? The estimation was influenced by management guys, the client absolutely needs it before Friday and we can t afford to not complete the task. Please estimate the effort carefully. The existing software architecture is very complex and implementing things take too much time. Enough impact analysis was not done Some other work, useful/useless meetings pulled the people out The quality of the work was bad and finally fixing the issues took more time than anticipated 7

8 Boehm s uncertain cone 8

9 Zoo points What value in zoo points would you use to wash these animals? Harder 10 and easier 1 More or less time consuming? Twice as big Half as big Almost but not quite as big A little bit bigger Lion Kangaroo Cat Giraffe Gorilla Hippopotamus Tiger

10 Can groups be beneficial in a software estimation context? As of today, most professional are probably subject to a series of group processes when estimating a project Warning! Much of the traditional software engineering literature misinterprets and simplifies psychological research on groups Lack of empirical research Research in software estimation has found that group processes might reduce over-optimism, and increase estimation accuracy, but there are many aspects to consider Which process is used to combine estimates? How is the project climate (customer, priorities, management)? Who are the participants? 10

11 Relative Estimation Identify a medium sized story that is well understood; call it a 5 Now estimate other stories relative to that Is it about the same, ½ as difficult, twice as difficult? Use a set of numbers that make sense; Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21 If bigger than that or if too hard to estimate, split the story Tackle as a team; Planning poker can help

12 Story Points Use Story Points as a relative measure of the size of a story. Relative compared to other stories Story points designate the effort required to complete the user story, not the priority or the value of the user story Each of these numbers should be thought of as a bucket into which items of the appropriate size are poured. Rather than thinking of work as water being poured into the buckets, think of the work as sand. If you have a story that you think is just the slightest bit bigger than the other five-point stories you've estimated, it would be OK to put it into the five-point bucket. A story you think is a 7, however, clearly would not fit in the five-point bucket. 12

13 Story points The bigness of a task Influenced by How hard it is How much of it there is Relative values are what is important: A login screen is a 2. A search feature is an 8. Points are unit-less Use 0 and ½ if you like Comparing a user story to others This story is like that story, so its estimate is what that story s estimate was.

14 Planning Poker This method was described first time by James Grenning in 2002 and later get popularized by Mike Cohn in the Agile Estimating and Planning book. The best way I ve found for agile teams to estimate is by playing planning poker (Grenning 2002) This method tries to make the meetings more short and productive, by making them more fun and dynamic.

15 Planning poker An iterative approach to estimating Steps Each estimator is given a deck of cards, each card has a valid estimate written on it Customer/Product owner reads a story and it s discussed briefly Each estimator selects a card that s his or her estimate Cards are turned over so all can see them Discuss differences (especially outliers) Re-estimate until estimates converge

16 Planning Poker

17 The meeting (I) 1. A deck is given to each of the members. 2. The moderator exposes a user story in no more than 2 minutes. 3. Time for questions about the user story. 4. Each of the members choose a card privately. 5. Once everybody has chosen, all the cards are turned over at the same time. 6. In this first round, it s probably that the estimations will differ significantly.

18 The meeting (II) 7. In case the estimations differ, the high and low estimators expose their reasons. 8. A few minutes for the team to discuss about the story and the estimation. 9. Again, each member thinks privately a estimation, and they show the cards simultaneously. 10. If the estimations still differ, the same process can be repeated.

19 The meeting (III) 11. When the estimations converge, the process finishes and the next user story is estimated. 12. In case the estimations don t converge by the 3 rd round, there are some options: Left the user story apart and try again later. Ask the user to decompose the story in smaller parts. Take the highest, lowest or average estimation.

20 Example (I) User story: PCGEEK wants to be able to create sell orders. Team of 7 members. First round: 3 rd and 6 th members expose their reasons for their estimations.

21 Example (II) 2 nd round: All members have converged except for the 3 rd A new round of expositions and voting can be made. It s also possible to take 3 or 5 as the estimation.

22 Example (III) 3 nd round: All members have converged

23 Variations Of course, it s an open method. There are some variations that can be applied: Use 2 cards instead of 1. Ask any member about his estimation, not necessarily the highest and lowest. Use more or less rounds.

24 Advantages Multiple expert opinions. The dialogue between the members result in more accurate estimations. Studies have shown that averaging estimations and group discussion lead to better results. Avoids only having estimates from the most senior individual Combines knowledge from several sources It s fun!

25 Disadvantages Meetings with all the team are expensive. The moderator needs to be careful and control the meeting so it doesn t get too long. Some factors can interfere in the estimations: dominant personalities, company politics Activities are not independent Discussions can end in polarized estimations.

26 Velocity

27 Velocity Now that stories have sizes, you can track how many points you typically get done in an iteration You can now use this to predict future completion rates

28 Release planning Release Planning Meeting Release Plan Sprint 1 Sprint 2 Sprint 3 Sprints 4 7

29 An example with velocity = 14 Story A Story F Sprint 1 Sprint 3 4 Story A Story B 5 3 Story H Story J 5 8 Story B Story G 13 Story E Story I Story C Story H Story C 3 Story D 5 Sprint 2 Story F 3 Story G 3 3 Story D 5 Story E 1 13 Story I 5 Story J 8

30 Q&A 30

31 More information The Wisdom of Crowds, James Surowiecki, 2004 Agile Estimating and Planning by Mike Cohn Agile and Iterative Development: A Manager s Guide by Craig Larman 31

32 Thank you!

33 Por favor no olvide llenar su encuesta y pedir un ticket para los sorteos de NetBooks y mochilas. 33

34 34