How to Estimate An Agile Backlog
0 likes53 views
This document discusses agile backlog estimation. It explains that providing high-level estimates for the product backlog can help both the business and development team. The estimates allow the business to prioritize work based on expected benefits versus effort. It also allows the development team to better predict what they can deliver and when. The document then provides suggestions for how teams can estimate items quickly without getting bogged down in discussions, such as having developers' votes outweigh others and establishing story point ranges that don't require discussion. It emphasizes that estimation is a planning exercise, not a commitment, and that working together creates shared understanding of the effort.
How to Estimate An Agile Backlog
- 2. In agile, providing “high level” estimates for the product backlog... 2
- 3. Can be injurious to health 3
- 4. 4 *Nota Bene: Parts of this presentation have been adapted from Fast estimation: A better approach to agile estimation by Anthony Crain.
- 5. Then, why do it? When technical teams estimate backlog items (epics, features, stories, tasks and bugs) using their extensive experience and expertise, it helps both the business as well as the team doing the estimates. 5
- 6. Decide priority Business stakeholders can prioritize work based on the expected benefits vs cost of effort for any given backlog item 6
- 7. Make predictions Technical teams can make better long-term predictions of how much they can deliver and by when 7
- 8. Look ahead Technical teams become aware and knowledgeable about upcoming features and changes 8
- 9. So, how do we do it? First, establish some ground rules that will help the team estimate fast without getting bogged down by excessive discussions 9
- 10. Suggested working agreement 1. The votes of the members doing the actual work (DEV and QA) trump everyone else (PO, BA, TA, MGT) 2. If the vote shows we all agree, we’re done; no discussion required 3. If the vote is one story point category off (5 vs 8), pick the higher number; no discussion required 4. If the vote is two story point categories off (3 vs 8), pick the middle number, 5; no discussion required unless the voter(s) with the higher estimate feel strongly about their estimates 5. If the vote is more than two story point categories off, discuss and revote 10
- 11. Suggested technique In a timeboxed manner, for a given backlog item: ▷ Business analyst or product owner discusses high level business or user requirements ▷ DEVs and QAs ask questions ▷ If questions cannot be answered, we make assumptions (for the sake of the estimate) and document them ▷ DEVs and QAs estimate together in agreed upon units (T-shirt sizes, Fibonacci numbers, apples, oranges, etc.) 11
- 12. Nota bene 12
- 13. But not at the cost of quality 13
- 14. Bear in mind ▷ If you don’t estimate, someone else will do it for you (they already do; you just don’t know it) ▷ Agile estimation is a planning exercise, not a promise or commitment ▷ Working together will help create a shared understanding of what the effort will likely be 14
- 15. 15 Because as they say...
- 16. “Plans are worthless, but planning is everything. - Dwight D. Eisenhower 16
- 17. Credits ▷ Presentation template by SlidesCarnival ▷ Slide 3 image ▷ Slides 12 & 13 image 17
- 18. Thanks for your time! Have questions, comments or feedback? Please feel free reach out to me on LinkedIn. 18