1. Estimating
1.1. Fibonaci Sequence
1.1.1. 1
1.1.1.1. 2
1.1.1.1.1. 3
1.2. Estimate the size of the problem
1.2.1. NOT
1.2.1.1. the solution
1.3. Relative Estimating
1.3.1. focus on
1.3.1.1. is this problem most like this other problem?
1.3.1.2. NOT
1.3.1.2.1. just the points on the basis of points
1.4. Starting
1.4.1. Start by picking something small
1.4.1.1. not smallest
1.4.1.2. call it a 2
1.4.2. Do all estimates relative to that story
1.4.2.1. just to get started
1.4.2.2. eventually they can be relative to each other after that
1.5. Be aware of diminished return on investment when estimating
1.5.1. accuracy goes up, then back down after too much effort in estimating
1.6. Re-Estimating
1.6.1. Should only re-estimate only when we believe a story's relative size has changed
1.6.2. When Not to Re-Estimate
1.6.2.1. Estimated 4 stories at 3 thinking they could get 12 points done
1.6.2.1.1. only got 6 done
1.6.2.2. Velocity Is the Great Equalizer
1.6.2.2.1. As long as stories are consistent and relative, velocity will average out correctly, that's its purpose
1.6.2.2.2. Velocity is an ever changing number, it will compensate for in-precise release planning estimates and update the planning estimates to be more accurate with each iteration
1.6.2.3. Re-Estimating in hindsight mixes estimates with work done, and looking forward we don't know which stories will also need to be re-estimated in hindsight or are actually correct
1.6.3. When To Re-Estimate
1.6.3.1. Example
1.6.3.1.1. Team works a story with an aspect of charting
1.6.3.1.2. Charting took a lot longer than they thought
1.6.3.1.3. They should NOT re-estimate just the original, or do no re-estimating
1.6.3.1.4. They should re-estimate all stories with a charting aspect to update the relative size of those stories with a now known quantity
1.6.4. Re-Estimating Partially Completed Stories
1.6.4.1. Velocity generally should be an all or nothing mentality
1.6.4.1.1. it will be lower one sprint, but then be higher the next
1.6.4.2. If the unfinished portion of a story will not be done in the next sprint
1.6.4.2.1. Split the story into 2 and re-estimate both
1.6.4.3. Or, don't have partially complete stories, finish them all
2. References
2.1. Grooming/Refinement
2.1.1. Mike Cohn
2.1.2. agile alliance guide
2.2. Estimating
2.2.1. Mike Cohn
2.2.2. Axis Agile
2.3. Agile Estimating and Planning Book Notes
3. Activities
3.1. Removing stories that are no longer relevant
3.2. Creating new stories in response to newly discovered needs
3.3. Re-assessing the relative priority of stories
3.4. Assigning estimates to stories which have yet to receive one
3.5. Better define stories
3.5.1. update story phrasing
3.5.2. add acceptance criteria
3.5.3. add notes
3.6. Correcting estimates in light of newly discovered information
3.7. Splitting stories which are high priority but too big to fit in an upcoming sprint
4. Best Practices
4.1. Planning Poker
4.1.1. Best approach according to Cohn
4.1.2. Combines all of the deriving techniques above
4.1.3. How to play
4.1.3.1. every team member gets a deck of cards
4.1.3.1.1. 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100
4.1.3.2. moderator reads the description of a story
4.1.3.3. Product owner answers any questions that the estimators have
4.1.3.3.1. keep in mind the effort/accuracy curve during this phase
4.1.3.4. Each estimator privately selects a card representing their estimate
4.1.3.4.1. cards are not shown until all estimators have made a selection
4.1.3.5. All cards are shown sumltaneously
4.1.3.6. If differing numbers appear, high and low estimators explain their esimates
4.1.3.6.1. goal is to learn what they were thinking, not an attack
4.1.3.7. Few more minutes of discussion
4.1.3.7.1. notes are taken on the story so that discussion is not wasted
4.1.3.8. Re-estimate occurs by cards again
4.1.3.9. Convergence or repeat
4.1.3.9.1. does not require everyone to throw the same card, if off by 1 or 2, ask if it's okay for convergence
4.1.3.9.2. does not require everyone to throw the same card, if off by 1 or 2, ask if it's okay for convergence
4.1.4. Right Amount of Discussion
4.1.4.1. to help not go too far right on the effort/accuracy curve
4.1.4.1.1. buy a 2 min sand timer
4.1.4.1.2. anyone can flip it over at any time, no scheduled use
4.1.4.1.3. after the timer, everyone picks/shows cards
4.1.4.1.4. discussion can continue again, but someone can immediately flip the timer also
4.1.5. Smaller Sessions
4.1.5.1. it is possible to planning poker with a subset of the team
4.1.5.1.1. not ideal
4.1.5.2. At least 3 people to do this
4.1.5.3. Good idea to focus on analogy estimating for this to work well
4.1.6. When to play
4.1.6.1. A few sessions a the start of a project to kickstart stories and estimates
4.1.6.2. plan to hold a very short estimation meeting near the end of each iteration
4.1.6.2.1. This keeps up on new stories as they are added and prioritized
4.1.7. Why Planning Poker Works
4.1.7.1. Brings together multiple expert opinions
4.1.7.2. Lively dialogue ensues during planning poker
4.1.7.2.1. estimators are called by their peers to justify their estimates
4.1.7.2.2. improves accuracy of estimates, especially on items with large amounts of uncertainty
4.1.7.2.3. result in estimates that better compensate for missing information
4.1.7.3. Averaging individual estimates leads to better results
4.1.7.4. It's fun
4.2. Attendance
4.2.1. Product Owner
4.2.2. Most of the team