This was the best i have ever seen regarding estimation in Agile, even various online courses would not be able to tell this in their 5 hour recordings. Thanks
It took my lecturer 4 three hour classes to explain this and I still left confused at the end. You did a fantastic job explaining everything in just 11 mins. Very well explained. Thank you 🙌🏻
I took several online courses, and none of them could explain how to properly do an estimation. This is the best explanation on the web! Thanks so much for sharing!
every time someone asks me, what the idea behind the story points is, I am sending him this video because it really left no open questions, thx for the good work!
My friend, if there is a word more that excellent job, pls let me know!. You have done an excellent job that the majority of Agile Instructors couldn't manage to do in 3 days of continuous talking. Pls keep the good job up! Your fan, from Iraq 🇮🇶
Great video. In summary: In agile estimation, story points are used as an abstract time unit to avoid absolute time estimates, while value points measure task importance. The Fibonacci sequence is favored for story and value point estimation in agile because it fits human thinking.
LOL....it's Sept 2020, 6 years after this video. And I have to EXCELLENT. This is the best video., It is bang on with exactly what I've seen happen with my development team.
The following could help in some situations. Ann Latham suggested the following assessment: 1. Unfamiliar Complex 2. Unfamiliar Simple 3. Familiar Complex 4. Familiar Simple
We don't have value point concept in our project as customers don't accord such point to a story. Product owner prioritised stories depending on how important it is for release deployment, in consultation with client. I enjoyed this video since explanation is incisive and invokes tremendous interest amongst Agile practitioner.
Thank you. That was very very helpful. Value points for this video 89, Story points, 13, BFTB = 6.8. This was on the top of my list. I shall mark the estimation task done now.
Nice video, thanks. What is the point of all the ordering, prioritization processes & calculations until the BFTB sores & reordering, if the team would still have to brainstorm & reorder finally based on the dependencies? why not just prioritize based on the dependencies in the first place instead? like in the traditional PM
The best video yet! Just went through this sizing exercise yesterday at my job but had no idea how to apply. This is going to be so helpful for our next meeting. I understood the whole Fibonacci number adding, but how to apply it. That is where I needed help. Thank you!
Fantastic tutorial! Just like the formula for calculating the Bang for the Buck, is there a formula to calculate the velocity and the time taken for the user story to be completed even for the 1st iteration? Thanks in advance !
Hello Soorya. The first iteration is when you really are guessing based on virtually no evidence (other than any other similar projects you work on). The good news is that *after* the first iteration you start to gather real world knowledge (the number of points you completed) which you can feed back in to future iterations. Over time, the estimates get more and more accurate.
I love this but am struggling with what the context of the "customer" is. (From 3:30) For example, if we are doing a site redesign and the first deliverable is the global header, how do we estimate the value from the customer's perspective? The new header is a number of epics, broken down into smaller pieces, naturally. But the customer needs every bit of each epic of it for it to be a new user experience. So how does one estimate something like that from the customer's perspective? Does anyone have any thoughts?
It's important to bear in mind that a story defines something of distinct value to the customer. In that sense, it can theoretically be delivered on its own. If you need to have multiple "stories", then it might be that they are not stories, but features or tasks. Consider evaluating your stories against the INVEST criteria: agileforall.com/new-to-agile-invest-in-good-user-stories/ Each story should be: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
This is good. The 'bang for the buck' calculation is awesome. However, using the Fibonacci sequence as a way to estimate story points is not realistic and actually would superimpose a rigid time structure per story. Your longest story may be a number that would break the Fibonacci sequence and you may have tons of smaller stories with similar or even exact story point numbers and maybe just a few larger stories (or vice versa) that won''t follow the sequence at all. Also, I do understand delivering value early but it is really the customer that is going to let you know what they want built first and then you meet with the team to see what is realistic or not and try to be as close to what the customer wants built as possible. That may mean a lot of smaller stories early or it may mean just larger stories...in my experience, we usually start working on bigger stories and tie in smaller stories for the initial Sprint...usually it balances out. It is usually best to focus on building, testing and deploying a smaller story that is of high value first so the customer can see it, test it out and be happy while your team works on bigger stories (if possible!). The video does a good job in presenting what should be the velocity for each Sprint (which does usually drop)...overall, a very good video with some great points...but note that it will never be as clean as estimating things in terms of the Fibonacci sequence.
if using the Fibonacci sequence as a way to estimate story points is not realistic and actually would superimpose a rigid time structure per story, what do you prefer to use for story points estimation?
Nice explanation but not sure about the name "agile estimation". The Manifesto for Agile Software Development makes no mention of story points. So why are story points referred to as "agile estimation", I assume it is because a few frameworks include this style of estimation. Unfortunately it gives the impression that you are not agile if you don't use story points. Maybe it should be called Fibonacci estimations or story point estimations or scrum estimations?
Does it really matter how it is named? Agile frameworks estimate in work effort, while Waterfall estimates duration. The primary goal is to determine how much work a team can have in process at a given time (WIP limit) and when the MVP will be done (velocity.)
@@scotttheus9529 yeah it does matter because agility has nothing to do with your estimation style. And the moment a person implies that part agility is to do estimations in a specific way, that person has lost the plot of what agility is. By correctly defining agility you are able to start taking advantage of its benefits.
@@brandonpearman9218 I understand and agree that "agile estimation = story points" takes away from agility. I also agree that by not mentioning other means of estimation the video implies by omission that story pointing is the only "agile" technique, and that the Fibonacci scale is the only "agile" method to determine the points of a story. Any good Agilist worth the paper their cert is printed on knows that this is not true. My point is that "story points ∈ agile estimation;" they are an element of all the estimating techniques used for agile frameworks. The Agile Manifesto makes no mention of estimations at all, the Scrum Guide discusses estimates, but does not name a single technique, and the video uses a very common method used for estimating stories.
@@scotttheus9529 yeah sure, i get you. I think we on the same page regarding meaning. But if i were to re-express my point, my concern is using language which the broader community may take and limit the views and techniques for agile software development. This is a valid concern because it has been happening the past 20 years, and now most people don't actually know the difference.
It generally would be. There's nothing to stop anyone using a poker-type game to make absolute estimates. But you are likely to adapt more to reality if you use it for relative estimates.
Hi this very informative, however I don't see how it can work within a construction contract scenario for example JCT ect ??? all it basically gives you is a predicted Program of works with a cash flow forecast????????
Very informative and I appreciate you sharing your experiences and knowledge. Could you please guide on the following: 1. Conducting a story point estimation throughout cross functional team means 1 representative from every functional group or all team members across organization? 2. A developer estimate 3 points for story vs tester estimate 8 points. Tester has to perform cross browser testing hence the scope of testing is large + different permutations/combinations to test the business rules. Which one will be taken as correct story point: 3 or 8? 3. Is there a baseline for effort based on story points e.g. 1 story point take 4 hours, 2 take 6 hours and so on 4. Say story point estimate consensus built on 3 story points. How do you schedule it if it's a 3 hour estimate by team. I mean in the end it will be development, testing, bug fixing, regression so will it be 3 hours each all the tasks together or 12 hours i.e 3 hours × 4 tasks
Hello Rhea, It was actually turned into a full course by O'Reilly Media, which I drew and my wife narrated www.oreilly.com/library/view/the-agile-sketchpad/9781771376099/
Conflating story points with time is a fundamental misunderstanding of their use. They’re meant to convey complexity and risk. The reason we remove time from points is because different developers code at different rates of speed but, as a team, we need a way to relatively size the lift, agnostic to developer…
The whole point of story points (pun?) is to abstract away time. i.e. - Don't correlate story points to hours. If you want to use hours, just use them and leave story points out of the conversation.
How can the 'value-points' model apply to teams that have multiple, discrete stakeholders? How can the value-points of different stakeholders be evaluated against one another?
but during 1st iteration how did we know that 2 weeks of sprint was enough to complete build wall story? please correct me if I have missed something, thanks you.
Can you answer me, do we do the estimation during the sprint planning? If not, in what moment of the project must we estimate the value and story points for each task?
Typically just prior to it (eg day before). You’ll get into a regular cadence. Don’t forget it’s relative so you are re-estimating the new backlog items with the existing ones. Since it’s a reoccurring, sustained activity you may want to introduce a ceremony for it at whatever cadence makes sense for your team.
I was trying to apply this method, not to development, but on prioritizing some company projects. Then I found that the projects have an additional variable, which is material costs. That variable is not specifically considered in this model - let's say for development some of the stories require buying hardware or software which is not effort, but nevertheless affects the decision making process. Value and effort can be the sae for two stories, but one requires HW or SW costs which makes the other one a higher Bang for the buck. Would you favor this cost be abstractly considered in the Story Points? Or should we incorporate the actual cost of materials per story and incorporate via formula in Story Point or as a third number in calculation. Such as Value Points / (Story Points + Material Cost Points)?
Quick question, how do you know that the first estimate you make of 55 is right? You just said we make estimtes bad without anything relative? Doesnt that also mean that when you @wrongly say 55 every other estimate between the lowest and highest will be wrong? Thanks!
Hello Kasper. Apologies for taking so long to reply. I'd missed you'd asked a question :) All estimates are guesses, and so when you guess that the 55 story point story is about 26x the 2 point story, you may well be wrong. But you will find through the iterations that your guesses will become more accurate. Why? Because you will have more and more completed stories and real world experience on the project, with a given team of people. Please note, that story points *are* relative. In the example the smallest story was given the value 2, and the largest given the value 55. You could have given the smallest story 21 points, and the largest 610 points. The ratio of 55:2 is pretty close to 610:21 (610, 21, 55 and 2 are all Fibonacci numbers). What matters is the relative size of the smallest to the largest. What those story points translate into actual hours and minutes will become clear as the project progresses. In reality, you might not even care what 1 story point equates to in absolute, because all that really matters is making an estimate as to how much work you are likely to complete in the next iteration. Apologies for the long, waffly response. I hope this helps :)
How do dependencies come into play? You may have roof as the greatest value but you can't get it in because realistically, you have to pour the concrete for the foundation first, then build the walls, etc... until you can actually get to the roof.
How do we make sure that value point is always greater than the story point? I see that this should be mandatory for division. What do we do if we have story point 20 and value point 10?
Hi Peeya, Just a friendly input here, Story Point and Value Point are two different items, they are not dependent with each other. In a way we can say Story Point pertains to size of work while Value Point lean towards prioritization (A must have VS good to have) of work/feature. With this in mind it does not matter which one is higher, SP or VP as long you include the decimal place in your BFTB the result should hold true when you sort it.
A must to react now. When you placed the number 55 then the sequence ref of said math equation I came up with 6 in my head instantly. IMO trim back considering the mean value of constant for think of waveforms in relativity to WL•WH=? Use this formula perhaps and input the variables that still give continuity but the end sum be greater as I work out the details? One wave pattern I am thinking that is off the top of my head is sound wave pattern is the fastest with less resistance. Watch bottom factor being input as HRR = >44 within no lower limitations than given as for the limiter revv max constant mild variable w/given range of 120.0_ 130. Hope this helps.
I am a certified Agile Coach, and this is probably the best Agile Estimation explanation I have ever seen. Thanks for sharing.
This was the best i have ever seen regarding estimation in Agile, even various online courses would not be able to tell this in their 5 hour recordings. Thanks
So True
It took my lecturer 4 three hour classes to explain this and I still left confused at the end. You did a fantastic job explaining everything in just 11 mins. Very well explained. Thank you 🙌🏻
The balancing between the story point and value point using "Bang for the buck" is important! Nice explanation
I took several online courses, and none of them could explain how to properly do an estimation. This is the best explanation on the web! Thanks so much for sharing!
every time someone asks me, what the idea behind the story points is, I am sending him this video because it really left no open questions, thx for the good work!
My friend, if there is a word more that excellent job, pls let me know!.
You have done an excellent job that the majority of Agile Instructors couldn't manage to do in 3 days of continuous talking.
Pls keep the good job up!
Your fan, from Iraq 🇮🇶
you're very kind what you invested in your video with , everything's clear you just helped me lots !
Great video. In summary: In agile estimation, story points are used as an abstract time unit to avoid absolute time estimates, while value points measure task importance. The Fibonacci sequence is favored for story and value point estimation in agile because it fits human thinking.
This is the simplest and best explaination of the agile estimation in limited time. Thanks a lot.
LOL....it's Sept 2020, 6 years after this video. And I have to EXCELLENT. This is the best video., It is bang on with exactly what I've seen happen with my development team.
Standing ovation! this is the best explanation of story points I have come across in my career as an agile developer. Thank you so much!
Absolutely!
This is EXACTLY how I want everything in life to be taught.
So brilliant! Thanks
Excellent explanation - most comprehensive video on this topic so far
The following could help in some situations. Ann Latham suggested the following assessment:
1. Unfamiliar Complex
2. Unfamiliar Simple
3. Familiar Complex
4. Familiar Simple
thanks so much for your clear explanation!!!
Great. i did not get the Agile estimation 100 % until i watched this. Thank you so much
We don't have value point concept in our project as customers don't accord such point to a story. Product owner prioritised stories depending on how important it is for release deployment, in consultation with client. I enjoyed this video since explanation is incisive and invokes tremendous interest amongst Agile practitioner.
I can't believe this video is 6 years old but still very relevant to how to estimate agile! Thanks a lot!
...I can't believe this comment is 3 years old but still very relevant! LOL!
@@payrollcontinuouslearningp3096 hahaha. Indeed!
You are a good teacher , easy and makes sense ....not the bla bla bla .....insightful
Very nice explanation, Thanks so much!!
Very crisp and clear. Thanks for the video David.
Thanks a lot for this valuable and neet video! Very helpful.
Thanks a lot. Cleared every doubt in a most practical manner.
WOW..... You explained it really good. Very easy, short and fantastic.
Useful. Thanks for the detailed information given.
Short and sweet explaination.Thank you
Thank you. That was very very helpful. Value points for this video 89, Story points, 13, BFTB = 6.8. This was on the top of my list. I shall mark the estimation task done now.
Beautifully explained
simplest & best i have seen till now , keep it up. you rock
Nice video, thanks. What is the point of all the ordering, prioritization processes & calculations until the BFTB sores & reordering, if the team would still have to brainstorm & reorder finally based on the dependencies? why not just prioritize based on the dependencies in the first place instead? like in the traditional PM
This is, in all palpable sincerity the best explanation for agile estimation I’ve seen❤
Its such a great example for how story points works
Thanks so much, I struggled hard before this vid!
Absolute gold. Perfectly and succinctly put.
Very well explained. Clearly articulated the heart of the matter. Valuable !!
The best video yet! Just went through this sizing exercise yesterday at my job but had no idea how to apply. This is going to be so helpful for our next meeting. I understood the whole Fibonacci number adding, but how to apply it. That is where I needed help. Thank you!
perfectly Explained , Thanks
This was truly a great video. thank you.
very well explained ..Thanks
Outstanding -- had never heard of value points before.
Very clear explanation. And very nice mindmap. I now understand the whole picture
In 11 minutes you did what my Master's Degree PM' professor didn't do in two years. Hope he is not here in this chat :) Thanks
Good explanation and very calm voice. Good job! 👍
Great job! Clear and simple!
Awesome, never seen better elucidation in this topic!
thanks for making this digestible
Complex understanding is made very simple! Great to watch and understand the concepts. Thank you so much!
A clear-cut & very informative explanation. Maximum "Bang for the buck"!
The best explanation, thanks!
Outstanding presentation - simple and clear!
Excellent - thank you very much
Outstanding! Congratulations!
Awesome. This cant be explained any way better. Thank you..
David requesting you to please continue making such very valuable to all, Thanks
Well you ask me four years ago, so I should probably start doing them again :D
superb, very well articulated!!! Thank you.
Fantastic tutorial!
Just like the formula for calculating the Bang for the Buck, is there a formula to calculate the velocity and the time taken for the user story to be completed even for the 1st iteration?
Thanks in advance !
Hello Soorya. The first iteration is when you really are guessing based on virtually no evidence (other than any other similar projects you work on). The good news is that *after* the first iteration you start to gather real world knowledge (the number of points you completed) which you can feed back in to future iterations. Over time, the estimates get more and more accurate.
awesome video! GOLD content! thank you!
Great video. Thanks a lot for sharing!
You are sooo good at explaining. Thank you so much for this video ♡
Excellent, clear, easy to understand. Many thanks.
I love this but am struggling with what the context of the "customer" is. (From 3:30) For example, if we are doing a site redesign and the first deliverable is the global header, how do we estimate the value from the customer's perspective? The new header is a number of epics, broken down into smaller pieces, naturally. But the customer needs every bit of each epic of it for it to be a new user experience. So how does one estimate something like that from the customer's perspective? Does anyone have any thoughts?
It's important to bear in mind that a story defines something of distinct value to the customer. In that sense, it can theoretically be delivered on its own. If you need to have multiple "stories", then it might be that they are not stories, but features or tasks. Consider evaluating your stories against the INVEST criteria: agileforall.com/new-to-agile-invest-in-good-user-stories/
Each story should be: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Beautifully done!!! It makes so much sense to me.
I want to thank you from the core of my heart for explaining such a tedious topic with so simplicity.
Thank you. This was a useful overview of Agile estimation
Excellent explanation 🙌👏👏👏🤩🙏
Great stuff!!, please upload more videos.
I love this video so much!
Nice overview on Agile estimation. Loved the visuals and clear explanations. Thank you!
Good job 👏 👍
This is good. The 'bang for the buck' calculation is awesome. However, using the Fibonacci sequence as a way to estimate story points is not realistic and actually would superimpose a rigid time structure per story. Your longest story may be a number that would break the Fibonacci sequence and you may have tons of smaller stories with similar or even exact story point numbers and maybe just a few larger stories (or vice versa) that won''t follow the sequence at all. Also, I do understand delivering value early but it is really the customer that is going to let you know what they want built first and then you meet with the team to see what is realistic or not and try to be as close to what the customer wants built as possible. That may mean a lot of smaller stories early or it may mean just larger stories...in my experience, we usually start working on bigger stories and tie in smaller stories for the initial Sprint...usually it balances out. It is usually best to focus on building, testing and deploying a smaller story that is of high value first so the customer can see it, test it out and be happy while your team works on bigger stories (if possible!). The video does a good job in presenting what should be the velocity for each Sprint (which does usually drop)...overall, a very good video with some great points...but note that it will never be as clean as estimating things in terms of the Fibonacci sequence.
if using the Fibonacci sequence as a way to estimate story points is not realistic and actually would superimpose a rigid time structure per story, what do you prefer to use for story points estimation?
Nice explanation but not sure about the name "agile estimation". The Manifesto for Agile Software Development makes no mention of story points. So why are story points referred to as "agile estimation", I assume it is because a few frameworks include this style of estimation. Unfortunately it gives the impression that you are not agile if you don't use story points. Maybe it should be called Fibonacci estimations or story point estimations or scrum estimations?
Scrum guide does not mention this either :)
Does it really matter how it is named? Agile frameworks estimate in work effort, while Waterfall estimates duration. The primary goal is to determine how much work a team can have in process at a given time (WIP limit) and when the MVP will be done (velocity.)
@@scotttheus9529 yeah it does matter because agility has nothing to do with your estimation style. And the moment a person implies that part agility is to do estimations in a specific way, that person has lost the plot of what agility is. By correctly defining agility you are able to start taking advantage of its benefits.
@@brandonpearman9218 I understand and agree that "agile estimation = story points" takes away from agility. I also agree that by not mentioning other means of estimation the video implies by omission that story pointing is the only "agile" technique, and that the Fibonacci scale is the only "agile" method to determine the points of a story. Any good Agilist worth the paper their cert is printed on knows that this is not true.
My point is that "story points ∈ agile estimation;" they are an element of all the estimating techniques used for agile frameworks. The Agile Manifesto makes no mention of estimations at all, the Scrum Guide discusses estimates, but does not name a single technique, and the video uses a very common method used for estimating stories.
@@scotttheus9529 yeah sure, i get you. I think we on the same page regarding meaning. But if i were to re-express my point, my concern is using language which the broader community may take and limit the views and techniques for agile software development. This is a valid concern because it has been happening the past 20 years, and now most people don't actually know the difference.
Brilliant!
Is planning poker a relative estimation technique??
It generally would be. There's nothing to stop anyone using a poker-type game to make absolute estimates. But you are likely to adapt more to reality if you use it for relative estimates.
Well explained. Common topic with new information :) Thank you.
Hi this very informative, however I don't see how it can work within a construction contract scenario for example JCT ect ??? all it basically gives you is a predicted Program of works with a cash flow forecast????????
Thanks for taking a common topic and making it interesting video. Please add more videos
Very informative and I appreciate you sharing your experiences and knowledge. Could you please guide on the following:
1. Conducting a story point estimation throughout cross functional team means 1 representative from every functional group or all team members across organization?
2. A developer estimate 3 points for story vs tester estimate 8 points. Tester has to perform cross browser testing hence the scope of testing is large + different permutations/combinations to test the business rules. Which one will be taken as correct story point: 3 or 8?
3. Is there a baseline for effort based on story points e.g. 1 story point take 4 hours, 2 take 6 hours and so on
4. Say story point estimate consensus built on 3 story points. How do you schedule it if it's a 3 hour estimate by team. I mean in the end it will be development, testing, bug fixing, regression so will it be 3 hours each all the tasks together or 12 hours i.e 3 hours × 4 tasks
Very good method !
Awesome story drawing👍
This was sooooo good. Where can I get more of his Vid? I only saw 2 on this channel 😔
Hello Rhea, It was actually turned into a full course by O'Reilly Media, which I drew and my wife narrated www.oreilly.com/library/view/the-agile-sketchpad/9781771376099/
Conflating story points with time is a fundamental misunderstanding of their use. They’re meant to convey complexity and risk. The reason we remove time from points is because different developers code at different rates of speed but, as a team, we need a way to relatively size the lift, agnostic to developer…
Thank you.
This is awesome!
Very well explained!
The whole point of story points (pun?) is to abstract away time. i.e. - Don't correlate story points to hours. If you want to use hours, just use them and leave story points out of the conversation.
But I like the idea of assigning BV to stories. Helps Product Owners / Managers prioritize their backlogs
How can the 'value-points' model apply to teams that have multiple, discrete stakeholders? How can the value-points of different stakeholders be evaluated against one another?
Great explanation, thank you 😇😇😇
but during 1st iteration how did we know that 2 weeks of sprint was enough to complete build wall story? please correct me if I have missed something, thanks you.
Can you answer me, do we do the estimation during the sprint planning? If not, in what moment of the project must we estimate the value and story points for each task?
Typically just prior to it (eg day before). You’ll get into a regular cadence. Don’t forget it’s relative so you are re-estimating the new backlog items with the existing ones. Since it’s a reoccurring, sustained activity you may want to introduce a ceremony for it at whatever cadence makes sense for your team.
I was trying to apply this method, not to development, but on prioritizing some company projects. Then I found that the projects have an additional variable, which is material costs. That variable is not specifically considered in this model - let's say for development some of the stories require buying hardware or software which is not effort, but nevertheless affects the decision making process. Value and effort can be the sae for two stories, but one requires HW or SW costs which makes the other one a higher Bang for the buck.
Would you favor this cost be abstractly considered in the Story Points?
Or should we incorporate the actual cost of materials per story and incorporate via formula in Story Point or as a third number in calculation. Such as Value Points / (Story Points + Material Cost Points)?
Great work!
Thank you!
very well explained! Thank u.
Quick question, how do you know that the first estimate you make of 55 is right? You just said we make estimtes bad without anything relative? Doesnt that also mean that when you @wrongly say 55 every other estimate between the lowest and highest will be wrong? Thanks!
Hello Kasper. Apologies for taking so long to reply. I'd missed you'd asked a question :) All estimates are guesses, and so when you guess that the 55 story point story is about 26x the 2 point story, you may well be wrong. But you will find through the iterations that your guesses will become more accurate. Why? Because you will have more and more completed stories and real world experience on the project, with a given team of people. Please note, that story points *are* relative. In the example the smallest story was given the value 2, and the largest given the value 55. You could have given the smallest story 21 points, and the largest 610 points. The ratio of 55:2 is pretty close to 610:21 (610, 21, 55 and 2 are all Fibonacci numbers). What matters is the relative size of the smallest to the largest. What those story points translate into actual hours and minutes will become clear as the project progresses. In reality, you might not even care what 1 story point equates to in absolute, because all that really matters is making an estimate as to how much work you are likely to complete in the next iteration. Apologies for the long, waffly response. I hope this helps :)
Great!! Very well explained!
Kishore P. George h
All Scrum masters should go through this.
Best Explanation
How do dependencies come into play? You may have roof as the greatest value but you can't get it in because realistically, you have to pour the concrete for the foundation first, then build the walls, etc... until you can actually get to the roof.
How do you decide which point to give 21 vs 34? Maybe 0-5 is low, 8-13 med, and 21-55 is large?
I think He said that would be determined by the developers or whoever is doing the work..
How do we make sure that value point is always greater than the story point? I see that this should be mandatory for division. What do we do if we have story point 20 and value point 10?
Hi Peeya, Just a friendly input here, Story Point and Value Point are two different items, they are not dependent with each other. In a way we can say Story Point pertains to size of work while Value Point lean towards prioritization (A must have VS good to have) of work/feature. With this in mind it does not matter which one is higher, SP or VP as long you include the decimal place in your BFTB the result should hold true when you sort it.
Thanks. How do you set team velocity for first sprint when we start agile?
You don't, or just a rough ballpark estimate to get you going. Thus a good idea not to use 1 month sprints :-)
Robert Hoffmann thank you
A must to react now. When you placed the number 55 then the sequence ref of said math equation I came up with 6 in my head instantly.
IMO trim back considering the mean value of constant for think of waveforms in relativity to WL•WH=? Use this formula perhaps and input the variables that still give continuity but the end sum be greater as I work out the details? One wave pattern I am thinking that is off the top of my head is sound wave pattern is the fastest with less resistance. Watch bottom factor being input as
HRR = >44 within no lower limitations than given as for the limiter revv max constant mild variable w/given range of
120.0_ 130. Hope this helps.