That was truly awesome. I had difficulty understanding story points and used ideal hours. Your video cleared it up for me. Thanks. Great work Mr. Griffiths.
I really love this presentation, both what it shows, as well as the presentation method. I am already looking forward to having a bunch of stakeholders playing value poker with me - I believe they will be hestitant but absolutely understand what it is good for after having done it.
Someone forwarded this to me recently. It's clearly communicated. I understand the idea of relative sizing for both effort and value. But, the nit I have to pick in your example, and I know it's just to help teach, is the notion that you're asking people to prioritize walls against a roof and other critical components of a house. These are silly prioritizations as we all know we need both. The real concern is the thing not clearly in the backlog and that's the size of the house. Knowing that tells us more about how many walls, and how big of a roof we'd need. There's lots of other options when considering brick vs. wood vs. stucco vs. aluminum siding. These distinctions between the pieces that are necessary to make a viable house/product and the real levers that effect cost make this really hard in reality. Thanks for posting this video none the less. It really is good.
Hello Yogita, If you work in story points and value points rather than absolute time measures, then you can use this technique with any tool. Many organisations choose to work primarily from a story board, with appropriate details backed up on a system like Jira. Glad you enjoyed it :-) DG
I really liked the idea of BFTB!! One quick question though: Since you measuring in BFTB and also measuring the first interaction against the items on that sprint, how can you quantify individual completion during that cycle? Meaning, how can you produce the Burndown chart if the measure is not put in days... just got that one confusion on my mind. But again, excelent way to measure value and time together to prioritize with both IT and business side.
Hi, sorry for the slow reply It’s because the ratios between consequent values are roughly the same. So 3/5 is approx. the same as 5/8, which is approx the same as 8/13 and so on. Because the proportions are all roughly the same, it doesn’t matter much what value you choose for your shortest story. In the example in the video, we have chosen “2”. We could have easily chosen “21", and then we’d have been able to scale all the values accordingly. See en.wikipedia.org/wiki/Fibonacci_number#Limit_of_consecutive_quotients Hope this helps :)
Youc an also find out more here www.safaribooksonline.com/library/view/the-agile-sketchpad/9781771376099/. I think there is a lot more detail in lesson 4 . Happy viewing :)
I noticed that when determining story points, the values were 0-55. However, when determining value points, the values were 0-144. I know these values are decided by two different groups of people, but let's say I'm determining both values for a self project. Do you get a more accurate BFTB value by making your value point scale larger than your story point scale? Or should they be the same?
Pretty good demo on Agile estimation. Perfectly articulated. I watched it twice but for some reason, I was a bit confused at 5:39 where you stated the Story point score of 21 and the Value point score of 55. But when you started the demo with the calculation of Story point, you had the top score of 55. How did that 55 become a Value Point score at 5:39.
Hello Cecil, It's coincidence that they're the same. The numbers for value and story points are both Fibonacci numbers, which increases the likelihood that the same numbers will tend to appear. DG
Two questions: 1.How did you come up with the initial velocity of 55 ? 2.You said fibonacci process is followed to give story points. How are value points given for the stories? are they random numbers?
Hello Manoj, Apologies for the *very* long delay in replying. The initial velocities are created based on their relative sizes: the shortest story "feels" about 30 times smaller than the largest. The two Fibonacci numbers 2 and 55 were chosen because they have a ratio of roughly 1:30. Why 2 rather than another Fibonacci number like 21? Absolutely no reason, other than keep the numbers fairly small. I could have chosen 21 points for the smaller story and 610 for longest story. Those two numbers are both Fibonacci and have a ratio of roughly 1:30. HTH. DG
What you said is valid for Scrum, which is one Agile Framework (there are more). Business agility is not about roles, but about delivering value and addressing risk iteratively.
Wait! Is it me only or somebody can explain how and why we are dividing 55 by 21? Story points (55) are estimated by the devs, as Mr. David put puts it, OK , I get it. Now, he is bring the customer into the sequence who would be 'Valuing' the WHAT? The Story points? @ minute 5:15, he flips the Story points as Value points and , where does he get Story point 21 to divide 55? What's the FORMULA ?
We're dividing VP / SP (55/21= 2.6) to get BFTB (Bang for the buck score) score. Story point was always 21 not 55 (look at the section when he gives story point) value point from client was 55 (as customer decides what part is the most valuable for them)
I see a lot of "good explanation". For me it sounds anti pattern in Agile when the moment you used "time" in the video. Estimation is indeed a relative way of measuring something. Only in Agile, it's not about time, but effort and difficulty. It's easier to have this time in mind, but the whole goal of agile is to actually know if we are improving. Time doesn't actually tells is if we are improving. in a lot of cases, a relative very small ticket could take longer to work in because it's just takes more time. In my opinion, the moment we use the word "time" , there is a big chance you lost the team. If you have really mature teams, then maybe it will work, but most of the people who watch this video is to actually gain knowledge. So there can be improvement in the way estimating is done now. When you have teams who aren't yet in the maturity we want, this will cause people having the mindset on even if we explain it, the thought will result in time. And getting out of this anti pattern is very hard. It's a little the same with using story points + numbers. Especially when the mindset is still based on time, people want to compare time with the points. In the end the thought process will still end up in: "3 SP for a ticket that takes more or less 3 days". As before, with mature teams, this wouldn't be a problem, but for people who start or don't have the agile mindset and watch this video will have the understanding that time is still the way to estimate, even if it's relative.
Great to see you found it useful. Do get in touch if there is anything else regarding bespoke software development that you'd like our help or input on: Black Pepper Software: 01926 806 490
Darth Vader Thanks, went well actually, we have a module on Software Project Management, and yes, estimation for Agile came up. Video was a huge help,haha.
First of all customers buy the goals achieved from use not the physical aspects; secondly this approach will underestimate important critieria such as 'decoration and carpets'. For goodness sake, are you going to say build the roof and forget the carpets! In which case I am not interested in the offer thanks very much. I am sure this is useful for manufacturing but when you put a human in the loop you are dealing with systems that are different. Critically, customers are not hyper reductionists that can give points to a wall (unless you shove a questionnaire under their nose): this also is a functional view of value and omits that customers want goal achievement and interest from the outcome, it seems that only robots and engineers like hyper reductionism. Normal people couldnt care less for this. High value from a building without carpets and decoration LOL are you an engineer?
It's a simple example. In real projects, you'd have to take into consideration way more tasks (stories) than those listed down in the video, OBVIOUSLY!
That was truly awesome. I had difficulty understanding story points and used ideal hours. Your video cleared it up for me. Thanks. Great work Mr. Griffiths.
Thank you . Explained it very well with such simplicity.
Really excellent film, well done for making.
Absolutely superb video! What an awesome explanation! Thank you!!
Thank you! Clear, concise, good value ... appreciated!
Excellent and well paced explanation. Thanks!
This is an excellent, easy to understand explanation of basic agile principles. Thumbs
Great video
Fantastically explained.
Best and most Bang for the bucks description for estimation.
Nice and Crispy info...hats off for your preparation
excellent presentation
i would like to say thanks for this nice video.
Really enjoyed this video and love the Fibonacci sequence. Makes so much sense.
Thank you so much. Great video
Very clear and concise. To the point
Very well explained, this was the video i was looking for.....
Nice and clear explanation, thanks!
I really love this presentation, both what it shows, as well as the presentation method. I am already looking forward to having a bunch of stakeholders playing value poker with me - I believe they will be hestitant but absolutely understand what it is good for after having done it.
Someone forwarded this to me recently. It's clearly communicated. I understand the idea of relative sizing for both effort and value.
But, the nit I have to pick in your example, and I know it's just to help teach, is the notion that you're asking people to prioritize walls against a roof and other critical components of a house. These are silly prioritizations as we all know we need both. The real concern is the thing not clearly in the backlog and that's the size of the house. Knowing that tells us more about how many walls, and how big of a roof we'd need. There's lots of other options when considering brick vs. wood vs. stucco vs. aluminum siding. These distinctions between the pieces that are necessary to make a viable house/product and the real levers that effect cost make this really hard in reality.
Thanks for posting this video none the less. It really is good.
Yes you got me there Jeff :-) The examples were chosen because of the low cognitive overhead. Your examples are much better :-)
Found it very useful. Very descriptive and explained so well.
Very nice video
very good explanation
Very well explained, this was the video i was looking for. Thank you
ken meeus glad to hear that :)
This is very good stuff. This should be taught in grade school.
Well explained 👏🏽👏🏽👏🏽
Very nice video. What software do you use to create these videos?
Thanks this was very useful
Very beautifully explained!
I’m glad you enjoyed it Deepak :-)
You are superb! This is what i was looking for...
can you please also let me know if we can follow the same process in JIRA as well.
Hello Yogita,
If you work in story points and value points rather than absolute time measures, then you can use this technique with any tool. Many organisations choose to work primarily from a story board, with appropriate details backed up on a system like Jira.
Glad you enjoyed it :-)
DG
provide some estimation based on ideal time esti
Hello,
I really like your video, wich tool are you using to do such graphic facilitation ( video ) ?
Thanks
Hello Rafik,
It was created with a tool I wrote with my wife called "Sketchpad".
DG
No points do not equate to time. Agile is not about time estimation it is about feature estimation.
story points are a measure of relative effort...not time
Damn right. Impressive that this comment didn't get more likes.
Just wondering, with what kind of software do you create such presentations?
Hello,
It was created using a tool I wrote with my wife called "Sketchpad".
DG
Is this the only form of Scaled Agile or are there other forms? Thank you Process Geekoid, SFC, SMC, LSSGB, PMP
Scaled Agile - Less, Safe and Nexus come into my mind
I really liked the idea of BFTB!! One quick question though: Since you measuring in BFTB and also measuring the first interaction against the items on that sprint, how can you quantify individual completion during that cycle? Meaning, how can you produce the Burndown chart if the measure is not put in days... just got that one confusion on my mind.
But again, excelent way to measure value and time together to prioritize with both IT and business side.
Not really points do not equate to time.
Hi,
Do you happen to have a reference explaining why using Fibonacci sequence helps?
Hi, sorry for the slow reply
It’s because the ratios between consequent values are roughly the same. So 3/5 is approx. the same as 5/8, which is approx the same as 8/13 and so on. Because the proportions are all roughly the same, it doesn’t matter much what value you choose for your shortest story. In the example in the video, we have chosen “2”. We could have easily chosen “21", and then we’d have been able to scale all the values accordingly.
See en.wikipedia.org/wiki/Fibonacci_number#Limit_of_consecutive_quotients
Hope this helps :)
Youc an also find out more here www.safaribooksonline.com/library/view/the-agile-sketchpad/9781771376099/. I think there is a lot more detail in lesson 4 . Happy viewing :)
I noticed that when determining story points, the values were 0-55. However, when determining value points, the values were 0-144. I know these values are decided by two different groups of people, but let's say I'm determining both values for a self project. Do you get a more accurate BFTB value by making your value point scale larger than your story point scale? Or should they be the same?
Hi David Griffiths, I would really love an answer to this good question! Thanks
I also would like to know why the value points went up to 144 while the story points only went up to 55. Why didn't both cap out at 55 or 144 each?
Pretty good demo on Agile estimation. Perfectly articulated. I watched it twice but for some reason, I was a bit confused at 5:39 where you stated the Story point score of 21 and the Value point score of 55. But when you started the demo with the calculation of Story point, you had the top score of 55. How did that 55 become a Value Point score at 5:39.
Hello Cecil,
It's coincidence that they're the same. The numbers for value and story points are both Fibonacci numbers, which increases the likelihood that the same numbers will tend to appear.
DG
Thank you David. I'm going to watch this lecture again.
Two questions:
1.How did you come up with the initial velocity of 55 ?
2.You said fibonacci process is followed to give story points. How are value points given for the stories? are they random numbers?
Can you please reply ?
Hello Manoj,
Apologies for the *very* long delay in replying. The initial velocities are created based on their relative sizes: the shortest story "feels" about 30 times smaller than the largest. The two Fibonacci numbers 2 and 55 were chosen because they have a ratio of roughly 1:30. Why 2 rather than another Fibonacci number like 21? Absolutely no reason, other than keep the numbers fairly small. I could have chosen 21 points for the smaller story and 610 for longest story. Those two numbers are both Fibonacci and have a ratio of roughly 1:30.
HTH.
DG
To sophisticated. I wouldn't use this method in the real world.
Quick correction: there is no project manager in Agile processes. Just the PO, the scrum Master and the development team.
What you said is valid for Scrum, which is one Agile Framework (there are more). Business agility is not about roles, but about delivering value and addressing risk iteratively.
Wait!
Is it me only or somebody can explain how and why we are dividing 55 by 21?
Story points (55) are estimated by the devs, as Mr. David put puts it, OK , I get it.
Now, he is bring the customer into the sequence who would be 'Valuing' the WHAT? The Story points?
@ minute 5:15, he flips the Story points as Value points and , where does he get Story point 21 to divide 55?
What's the FORMULA ?
We're dividing VP / SP (55/21= 2.6) to get BFTB (Bang for the buck score) score. Story point was always 21 not 55 (look at the section when he gives story point) value point from client was 55 (as customer decides what part is the most valuable for them)
The only student here
For a completely different way of sizing, but one which is widely accepted, try COSMIC instead: czcams.com/video/HE6uq-geR7A/video.html
I see a lot of "good explanation". For me it sounds anti pattern in Agile when the moment you used "time" in the video. Estimation is indeed a relative way of measuring something. Only in Agile, it's not about time, but effort and difficulty. It's easier to have this time in mind, but the whole goal of agile is to actually know if we are improving. Time doesn't actually tells is if we are improving. in a lot of cases, a relative very small ticket could take longer to work in because it's just takes more time. In my opinion, the moment we use the word "time" , there is a big chance you lost the team. If you have really mature teams, then maybe it will work, but most of the people who watch this video is to actually gain knowledge. So there can be improvement in the way estimating is done now. When you have teams who aren't yet in the maturity we want, this will cause people having the mindset on even if we explain it, the thought will result in time. And getting out of this anti pattern is very hard. It's a little the same with using story points + numbers. Especially when the mindset is still based on time, people want to compare time with the points. In the end the thought process will still end up in: "3 SP for a ticket that takes more or less 3 days". As before, with mature teams, this wouldn't be a problem, but for people who start or don't have the agile mindset and watch this video will have the understanding that time is still the way to estimate, even if it's relative.
Great to see you found it useful. Do get in touch if there is anything else regarding bespoke software development that you'd like our help or input on:
Black Pepper Software: 01926 806 490
Anyone here from business Analysis?
Software Development.....I have an exam in an hour. Lord save me!
Bahaha, good luck my friend!
Darth Vader Thanks, went well actually, we have a module on Software Project Management, and yes, estimation for Agile came up. Video was a huge help,haha.
First of all customers buy the goals achieved from use not the physical aspects; secondly this approach will underestimate important critieria such as 'decoration and carpets'. For goodness sake, are you going to say build the roof and forget the carpets! In which case I am not interested in the offer thanks very much. I am sure this is useful for manufacturing but when you put a human in the loop you are dealing with systems that are different. Critically, customers are not hyper reductionists that can give points to a wall (unless you shove a questionnaire under their nose): this also is a functional view of value and omits that customers want goal achievement and interest from the outcome, it seems that only robots and engineers like hyper reductionism. Normal people couldnt care less for this. High value from a building without carpets and decoration LOL are you an engineer?
It's a simple example. In real projects, you'd have to take into consideration way more tasks (stories) than those listed down in the video, OBVIOUSLY!