I think you missed something about the accuracy of Fibonacci series in estimation. Yes, it prevents us to make absolute estimations, but it's more than that : it helps us to keep in mind that complexity is not linear. Let's take an example. If you have x=3, it's preaty easy to solve. Having 3x+2y=12 will take more effort to solve. 2x-7y*12z=-182 will be clearly harder. Adding variables will not add "x values of effort" to solve, it will be more a multiplication (x1,6 as you demonstrate) Going from 3 to 5 means it will take more effort than going from 2 to 3, rather than 3 to 4. The more complexity you have, the more effort it will take. That's why Fibonacci series is accurate in agile : it has a great psychological impact on us about the reallity of complexity
I can agree with the comment about considering non-linear complexity using Fibonacci which may help with better estimates, however; claiming that Fibonacci series gives you accurate estimates is far-fetched. It is well known in the realm of project/product management that estimates are rough due to unpredictable human/life factors.
I watched "Agile Estimating & Planning [2018] Fibonacci Series = Better Estimates?", and was disappointed . The title of the presentation said "better" estimates, but the entire presentation was about "accurate" estimates. "Accuracy" is not the only characteristic of a "Better" estimate. IMHO, ease for the developer to make a -useful- estimate is more important. Nonetheless, I set out to 'fix' my set of numbers to see what difference that made. It turned out that my original list of sizes was fine for me. If I want to make relative estimates, I pay attention to the relative -sizes- of the estimates, not the relative gaps between sizes as was assumed in the video. I have watched several of your other videos, and generally found them helpful. Thank you.
You are right to be disappointed: I have no idea why I wrote "better" in the title - I hadn't even noticed that I'd done so, so that's for letting me know. The mistake has now been corrected.
We used to. But a point was a day, and soon we did away with points and went with hours (except for my team, because I mocked the idea of that level of accuracy). Anyway that was a big mistake, so I'll be fighting for t-shirt sizes soon.
great video! thanks for making it. one of the best and simple explanation of the fibonacci usage in estimates. had to subscribe. keep up the good stuff sir!
Thank you! I showed this to my team and they began to understand the importance of relative estimates and how it ties to the Fibonacci sequence. Im curious, how do you figure out the relative increase percentage? My team took this relative gap to say, "as the percentage decreases, the effort of each point increases. What are your thoughts?
I’ve read chest sheet and I’m wondering - if I get You right You’r advice about estimating process is to ask many people and to ask questions like how many km are to dublin instead of when we’ll get there- but what if I must put a deadline ? How to estimate it rationally? Do You have tips?
Deadlines - for individual tickets - don't mix well with Agile. Here's why: if the time to develop a software feature was predictable... we wouldn't use agile!
The. target audience for this video appears to be those who are charged with managing software development teams. Like most tutorials on Agile or it’s components. But what is missing in almost all instructions on Agile are helpful instructions for the Worker Bees who are working in an Agile environment. Like most technical workers, I have no interest in becoming a manager and much less interest in being a Scrum Master. In my 4 decades of technical work I’ve always been baffled as to why senior managers like to take high performing technical workers and force them to do all the clerical work that goes with directing small to middle sized teams. Regarding this discussion of why a Fibonacci sequence is a wonderful example of how flawed Agile is. Yes your explanation of what the series is and the reality that once away from the first few numbers, the incremental increase between adjacent numbers converges on a fixed percentage increase. That reality has nothing to do with Agile and has been known for a couple of millennia. But in that respect, it is similar to many uses of the cosine function where in science and technology, there is a frequent need for a function with a shape similar to a cosine function. Since the cosine function is easy to describe and calculate, it is an attractive choice even though there is frequently no magic in the choice of cosine vs another similar shaped function. Project Management is an important function in any organization larger than a dozen staff. The needs of PM can easily become wasteful when the organization is working on objectives so innovative that things are dominated by Unknowable Unknowns. Certainly the motivation of Agile enthusiasts is laudable in that they want to reduce the waste of continually revising detailed Project Plans. But, Agile’s fatal flaw in that the Project Management staff who oversee the daily ,weekly, monthly implementation of Agile are generally technically weak on how to technical products that have business value.
Here's the link to the Agile Estimating Cheat Sheet: www.developmentthatpays.com/cheatsheets/agile-estimating
The linked cheat sheet has 20 instead of 21 in the example fib numbers
The link requires your email address so you can get more junk mail. no thanks, but you made a great video.
@@kolesplace - Drat! You saw right through my cunning plan!
I think you missed something about the accuracy of Fibonacci series in estimation. Yes, it prevents us to make absolute estimations, but it's more than that : it helps us to keep in mind that complexity is not linear.
Let's take an example. If you have x=3, it's preaty easy to solve. Having 3x+2y=12 will take more effort to solve. 2x-7y*12z=-182 will be clearly harder. Adding variables will not add "x values of effort" to solve, it will be more a multiplication (x1,6 as you demonstrate)
Going from 3 to 5 means it will take more effort than going from 2 to 3, rather than 3 to 4. The more complexity you have, the more effort it will take.
That's why Fibonacci series is accurate in agile : it has a great psychological impact on us about the reallity of complexity
I can agree with the comment about considering non-linear complexity using Fibonacci which may help with better estimates, however; claiming that Fibonacci series gives you accurate estimates is far-fetched. It is well known in the realm of project/product management that estimates are rough due to unpredictable human/life factors.
I watched "Agile Estimating & Planning [2018] Fibonacci Series = Better Estimates?", and was disappointed
.
The title of the presentation said "better" estimates, but the entire presentation was about "accurate" estimates. "Accuracy" is not the only characteristic of a "Better" estimate. IMHO, ease for the developer to make a -useful- estimate is more important.
Nonetheless, I set out to 'fix' my set of numbers to see what difference that made. It turned out that my original list of sizes was fine for me. If I want to make relative estimates, I pay attention to the relative -sizes- of the estimates, not the relative gaps between sizes as was assumed in the video.
I have watched several of your other videos, and generally found them helpful. Thank you.
You are right to be disappointed: I have no idea why I wrote "better" in the title - I hadn't even noticed that I'd done so, so that's for letting me know. The mistake has now been corrected.
We used to. But a point was a day, and soon we did away with points and went with hours (except for my team, because I mocked the idea of that level of accuracy). Anyway that was a big mistake, so I'll be fighting for t-shirt sizes soon.
great video! thanks for making it. one of the best and simple explanation of the fibonacci usage in estimates. had to subscribe. keep up the good stuff sir!
Great explanation. Do you have a video on building fibonacci burndown charts.
I don't. (I'm not a fan of burndown charts...)
Yep and they're crap. Great vid, thanks for confirming what I already knew is a concise manner!
Thank you! I showed this to my team and they began to understand the importance of relative estimates and how it ties to the Fibonacci sequence.
Im curious, how do you figure out the relative increase percentage? My team took this relative gap to say, "as the percentage decreases, the effort of each point increases. What are your thoughts?
I’ve read chest sheet and I’m wondering - if I get You right You’r advice about estimating process is to ask many people and to ask questions like how many km are to dublin instead of when we’ll get there- but what if I must put a deadline ? How to estimate it rationally? Do You have tips?
Deadlines - for individual tickets - don't mix well with Agile. Here's why: if the time to develop a software feature was predictable... we wouldn't use agile!
Development That Pays great answer as usual thx !
Good conclusion, thanks for the video.
estimste on what ? what is the units? time, length, weight, dollars, life expectancy…
Thank you! This was very helpful!
Glad it was helpful!
In my previous post, I tried to use '-' to emphasize. The crossout that resulted was an unintended consequence. Sorry.
No problem. Really appreciated the comment.
Nice explained...👍
Thank you! 👍
Nice
Nice explaining bro
Glad you liked it!
thanks for explaining this.
You're welcome!
Your cheat sheet has an error in the sequence - 20 not 21 - was that deliberate?
I need to sort this out: 21 is the correct Fibonacci number... and 20 is the correct Planning Poker card number. I've mixed/confused the two.
Hey Gary, can’t find the cheat sheet 🙈
Here's the link: www.developmentthatpays.com/cheatsheets/agile-estimating
Development That Pays thank you !!!
The. target audience for this video appears to be those who are charged with managing software development teams. Like most tutorials on Agile or it’s components.
But what is missing in almost all instructions on Agile are helpful instructions for the Worker Bees who are working in an Agile environment.
Like most technical workers, I have no interest in becoming a manager and much less interest in being a Scrum Master. In my 4 decades of technical work I’ve always been baffled as to why senior managers like to take high performing technical workers and force them to do all the clerical work that goes with directing small to middle sized teams.
Regarding this discussion of why a Fibonacci sequence is a wonderful example of how flawed Agile is. Yes your explanation of what the series is and the reality that once away from the first few numbers, the incremental increase between adjacent numbers converges on a fixed percentage increase. That reality has nothing to do with Agile and has been known for a couple of millennia. But in that respect, it is similar to many uses of the cosine function where in science and technology, there is a frequent need for a function with a shape similar to a cosine function. Since the cosine function is easy to describe and calculate, it is an attractive choice even though there is frequently no magic in the choice of cosine vs another similar shaped function.
Project Management is an important function in any organization larger than a dozen staff. The needs of PM can easily become wasteful when the organization is working on objectives so innovative that things are dominated by Unknowable Unknowns. Certainly the motivation of Agile enthusiasts is laudable in that they want to reduce the waste of continually revising detailed Project Plans.
But, Agile’s fatal flaw in that the Project Management staff who oversee the daily ,weekly, monthly implementation of Agile are generally technically weak on how to technical products that have business value.
66.66% correct estimate 33.33% wrong estimate
I use my own personal estimates
Do you work alone?
@@Developmentthatpays For me as a designer and for the team as project manager.
Just realised, your thumbnail missed "13".
Whoops. Good spot! Thanks for letting me know. (Fixed now.)