Download to read offline
More Related Content
Similar to Agile projetcs (sizing and estimation)
Agile projetcs (sizing and estimation)
- 1. Agile Projects Series Sizingand Estimation https://medium.com/expedia-group-tech/demystifying-story-points-d642f9879952
- 2. Agile Projects Sizingand Estimation Webinar Setup Please mute your microphones while you are listening Webinar is recorded We will accommodate questions depending on the timebox left
- 3. XP Days It'san initiative for gathering people interested in Agile, eXtreme Programming, Scrum, Coding, etc… It’s our 8th event Webinar is co-hosted with Agile Arena www.xpdays.org
- 4. Agile Arena AgileArena is an Agile Consulting and Training company www.agilearena.net
- 5. Ahmed Helmy • SoftwareConsultant • Founder of XP Days • Certified Scrum Master • Certified Scrum Developer • Certified Scrum Product Owner @helmy204 ahmedhelmy204@hotmail.com www.linkedin.com/in/helmy204 www.github.com/helmy204
- 6. Agenda • Product Backlogs •Estimation units and scales • Agile Sizing and Estimation Techniques
- 7. How long willit take to read this book?
- 8. Scrum Artifacts Product Level(Shared Vision) • Product Backlog Sprint Level (Sprint Goal) • Sprint Backlog • Product Increment https://www.scrum.org/resources/scrum-framework-poster
- 9. Product Backlog Sources •Requirements – New Features • Compliance • Defects • Technical Work • Infrastructure Enhancements
- 10. Product Backlog ItemLevel of Detail Kite Sea-levelCloud
- 11. Who is responsiblefor estimating features • Scrum Master • Tech Lead • Project Manager • Development Team • Product Owner
- 12. How long willit take to read these books? Group 1 Group 2 Group 3 Group 4 Group 5 سمرقند علي قمر 45 30 How to enjoy your life and your job 30 10 The Hobbit 30 15.5 خالد عبقرية 15 7.5 Thinking fast and slow 5 23 الصغار لمعانقة الصغير الكتاب 1 3
- 13. Estimation units Story Points •How long a user story will take (effort) • Influenced by complexity, uncertainty, risk, volume of work, etc. • Relative values are what is important Ideal Time • The time needed to complete a given task as if • It’s all you work on • No one interrupts you • And everything you need is available • Simple and easy to use, yet it can be easily understood by and explained to all stakeholders • The measure of ideal time varies from one person to another based on their own skills and competencies
- 14. Advantages of StoryPoints • Additive • Help avoid problems with unit confusion
- 15. How long willit take to read these books? Group 1 Group 2 Group 3 Group 4 Group 5 سمرقند علي قمر 40 30 30 How to enjoy your life and your job 15 10 12 The Hobbit 25 20 25 خالد عبقرية 15 10 10 Thinking fast and slow 25 25 35 الصغار لمعانقة الصغير الكتاب 1 1 1 1
- 16. Planning in aweek!
- 17. The XP solutionis to accept more risk in the plan by having bigger stories. Write stories you can estimate in terms of ideal programming months instead of ideal programming weeks
- 18. Estimation Scale • 1,2, 3, 5, and 8 (Fibonacci sequence) • The gaps in the sequence become appropriately larger as the numbers increase • 1, 2, 4, and 8 (each number is twice the number that precedes it) • These non-linear sequences work well because they reflect the greater uncertainty associated with estimates for larger units of work. Either sequence works well although my slight personal preference is for the first
- 19. What are sizingand estimation techniques you used to work with?
- 20. Agile Sizing and Estimation Bottom-upvs Top-down approaches T-Shirt Sizing Planning Poker Wideband Delphi Affinity Estimating Estimating with Pomodoros
- 21. Bottom-up vs Top-downapproaches • In the bottom-up approach all project requirements are defined up-front and then decomposed into the smallest possible pieces or tasks, then each task is estimated from the bottom and all estimations are summed up to the top till all project is estimated; then we have the project schedule. • Unlike traditional projects, Agile teams provide their estimates using a “top- down” approach; where we use current available information to produce gross- level estimation, and this estimation is less accurate and has less details. • When more information becomes available as the project progress, plans are refined until producing a detailed estimation on the tasks level in just-in-time basis • Incorporating new information and refining our estimation accordingly is known as rolling wave planning. • The top-down approach allows the team to react quickly to the changing project requirements or any other introduced changes.
- 22.
- 23. T-Shirt Sizing • Weneed to think of a non-numerical estimation method • The name of this technique came from the T-shirt sizing (XS, S, M, L, XL, XXL) • The team is free to think in a more abstract way about the effort involved in a story • Fun activity • They are generally less accurate • Aims to capture the initial estimation of features • It’s rough estimation that will be refined and groomed through out the project through progressive elaboration
- 24. Planning Poker Present individual stories forestimation Discuss Each participant chooses estimate from his deck Keep estimates private until everyone has chosen a card Reveal estimates • To play the game you would need a typical deck of cards showing a numeric sizes • At the begging of the game we all should agree on what represents “1”
- 25. Wideband Delphi • Eachof the participants submits his/her estimation in anonymous rounds • Define the problem • Create an estimation form for the work • Participants work alone to come up with the estimation • Facilitator collects the estimates and plot them on a graph • Participants discuss the estimates that vary widely • Estimation round is repeated till consensus starts to emerge
- 26. Affinity Estimating • Similarity •Grouping into affinities of similar size
- 27. Affinity Estimating • Thesize of each of the user stories is compared to other stories to ensure that all the estimates remain consistent • User stories are estimated collaboratively, using any estimating technique (T-Shirt sizing, Wideband Delphi, or Planning Poker,…) • Affinity estimation is not a technique for estimating the size of user stories, but it’s a technique for grouping the previously estimated user stories into affinities to ensure the consistency in size
- 28. Estimating with Pomodoros •25 minute work sessions followed by 5 minute breaks sessions • Cycle of fixed time boxes prevent mental fatigue • Each 25-5 minute cycle is called a Pomodoro • Every 4 Pomodoros is called a set • After each set you take 15 minutes break
- 29.
- 30. Summary Problem (Product Backlog Item) Solution (Tasks) WhoDevelopment Team Development Team When Product Backlog Refinement Sprint Planning Unit of measure Story Points, Function Points, Use Case Point, Ideal Days, etc., Hours How Planning Poker, Delphi, Expert Judgment, etc., Expert Judgment
- 31.
- 32.
Editor's Notes
- #8 569 pages Estimating by Analogy When estimating by analogy, the estimator compares the story being estimated to one or more other stories. When estimating this way you do not compare all stories against a single baseline or universal reference. Instead, you want to estimate each new story against an assortment of those that have already been estimated.
- #9 Why Estimates Estimated are necessary for sizing and approving projects Early estimates are required to calculate ROI, leading to deciding which projects to be selected Early estimates help in determining which piece of work can be done within each release or iteration
- #11 Definition of Ready Moving from Done Done to Ready Ready
- #12 The Agile Team who is going to perform the work is responsible for estimating The team is also committing to the rate of progress they can do according to the approaches to be used and their rate of progress The agile team is responsible to make decisions concerning how the work will be achieved and what amount of work can be done on a certain time frame The person responsible for implementing gets to estimate (xp)
- #13 569 pages Estimating by Analogy When estimating by analogy, the estimator compares the story being estimated to one or more other stories. When estimating this way you do not compare all stories against a single baseline or universal reference. Instead, you want to estimate each new story against an assortment of those that have already been estimated.
- #14 Story Points How long a user story will take (effort) Influenced by complexity, uncertainty, risk, volume of work, etc. Relative values are what is important A login screen is a 2 A search feature is an 8 Example: I can read book in a month and you read it in a week ( 1 point), if we got a book with double the size so we both agree that it’s 2 points Traditional software teams give estimates in a time format: days, weeks, months. Many agile teams, however, have transitioned to story points. Story points rate the relative effort of work. It may sound counter-intuitive, but that abstraction is actually helpful because it pushes the team to make tougher decisions around the difficulty of work. Here are few reasons to use story points: Dates don’t account for the non-project related work that inevitably creeps into our days: emails, meetings, and interviews that a team member may be involved in. Dates have an emotional attachment to them. Relative estimation removes the emotional attachment. Each team will estimate work on a slightly different scale, which means their velocity (measured in points) will naturally be different. This, in turn, makes it impossible to play politics using velocity as a weapon. Once you agree on the relative effort of each story point value, you can assign points quickly without much debate. Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time. Estimate smarter, not harder No individual task should be more than 16 hours of work. (If you're using story points, you may decide that, say, 20 points is the upper limit.) It’s simply too hard to estimate individual work items larger than that with a high degree of confidence. And that confidence is especially important for items at the top of the backlog. When something is estimated above your team's 16-hour (or 20-point) threshold, that's a signal to break it down into more granular pieces and re-estimate. For items deeper in the backlog, give a rough estimate. By the time the team actually begins to work on those items, the requirements may change, and your application certainly will have changed. So prior estimates won’t be as accurate. Don’t waste time estimating work that is likely to shift. Just give the product owner a ballpark figure she can use to prioritize the product roadmap appropriately. Relative Sizing and Story Points It’s easier for the human brain to compare 2 items instead of just guessing an estimate What is the size of an Orange? what’s the size of and Orange compared to a watermelon and a grape? It may be more difficult to estimate how long a particular feature will take to develop but it is relatively easy to guess if it is more or less complex than other features A story point is a metric used to estimate the difficulty of implementing a given item A story point is and abstract measure of the effort required to implement the item Ideal Time The time needed to complete a given task as if there is no interruptions In an 8 hours work day, it assumes that all the eight hours are available for work, and all other distractions and non-project work are eliminated Simple and easy to use, yet it can be easily understood by and explained to all stakeholders The main drawback is that the measure of ideal time varies from one person to another based on their own skills and competencies Planning in a Week The XP solution is to accept more risk in the plan by having bigger stories. Write stories you can estimate in terms of ideal programming months instead of ideal programming weeks How long something will take if: It’s all you work on No one interrupts you And everything you need is available
- #15 Example: I can read book in a month and you read it in a week ( 1 point), if we got a book with double the size so we both agree that it’s 2 points
- #16 569 pages Estimating by Analogy When estimating by analogy, the estimator compares the story being estimated to one or more other stories. When estimating this way you do not compare all stories against a single baseline or universal reference. Instead, you want to estimate each new story against an assortment of those that have already been estimated.
- #25 Planning Poker is played in a way that “influence between the participants” is minimized, therefore a more accurate estimation result is produced Usually teams used a modified version of the Fibonacci Sequence: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. to reflect the uncertainty in estimating larger items A high estimate usually means that the story is not well understood in detail or should be broken down into multiple smaller stories