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 🙌🏻
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
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!
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.
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 🇮🇶
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!
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.
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
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.
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.
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!
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
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…
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.
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
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.
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?
Funny like Scrum videos always consider things as projects.. We usually sit on feature or platform teams never project based just strings of epics so we measure constantly
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.
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?
It's okay up to a point. I only have a question in first iteration. When you are starting to first iteration of a new product, you gonna need to tell a roughly time that it is going to finish. You cannot say to the team that I have a story but I dont know how many sprints it is gonna take. Have you got answer for this question ?
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.
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)?
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????????
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 :)
It makes alot of sense to me, but this presentation is not taking into cognizance some key technical dependencies or requirements that often occasion the decision to start with stories with easier dependencies first before the much complicated ones ? I cannot wait to get some feedback on this
This explanation could have been perfect if you had used ‘new product development’ examples instead of ‘production work’ with little uncertainty. Dropping the story points and value points into the value/effort matrix would have been even more visually appealing rather than the calculated ratio. Other than that, i couldnt have explained it better... well done!
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/
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.
That extremely helpful. But please answer this question: How to we input Hours in all of this? If I calculate the team's capacity for the 1st Sprint of 2 weeks and I get total Sprint Hours how do I actually know how quickly each story point is done before having to wait until Sprint 1 is over, then look at Velocity and calculate back to how many hours it was. How do I calculate Hours forward. Should I even bother?
Don’t bother. Just use velocity to plan. Assuming you have a fixed team, it is easy to reverse engineer hours per story point based on velocity. Bu5 since you plan in story points, hours are pretty meaningless.
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.
This is a great explanation. However, not even a minute into it the presentation defined a story point as a measure of time, which is incorrect. The standard definition of a story point is measurement of "the relative work, risk and complexity of a requirement or story." (PMBOK Guide, 6th Edtion) Linking a story point to a unit of time is misleading and will result in teams taking the easy route by saying 1 story point = 1 hour.
Yep that's the point, thanks for your comment - that was the same what I thought. Maybe at the beginning with less knowledge you need for 3 SP more time than weeks later when you gained more knowledge or experience. The complexity of 3 SP will be the same but you are maybe faster and are able to produce more output in the same amount of time => velocity goes up. Never bind time to SP
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.
I still don't get it. It's like estimating distance in miles, then record it as Fahrenheit. During the estimation process, we slip in intimidating words like Fibonacci so people will think we know what we are doing
I am a certified Agile Coach, and this is probably the best Agile Estimation explanation I have ever seen. Thanks for sharing.
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 🙌🏻
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
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!
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.
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 🇮🇶
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!
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.
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
This is the simplest and best explaination of the agile estimation in limited time. Thanks a lot.
you're very kind what you invested in your video with , everything's clear you just helped me lots !
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!
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.
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.
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!
You are a good teacher , easy and makes sense ....not the bla bla bla .....insightful
This is EXACTLY how I want everything in life to be taught.
So brilliant! Thanks
Great. i did not get the Agile estimation 100 % until i watched this. Thank you so much
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!
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❤
Excellent explanation - most comprehensive video on this topic so far
WOW..... You explained it really good. Very easy, short and fantastic.
Thanks a lot for this valuable and neet video! Very helpful.
Very crisp and clear. Thanks for the video David.
Beautifully explained
Thanks a lot. Cleared every doubt in a most practical manner.
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…
Good explanation and very calm voice. Good job! 👍
Its such a great example for how story points works
Thanks so much, I struggled hard before this vid!
Useful. Thanks for the detailed information given.
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
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.
Very nice explanation, Thanks so much!!
Complex understanding is made very simple! Great to watch and understand the concepts. Thank you so much!
Very well explained. Clearly articulated the heart of the matter. Valuable !!
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 clear explanation. And very nice mindmap. I now understand the whole picture
Outstanding -- had never heard of value points before.
Absolute gold. Perfectly and succinctly put.
simplest & best i have seen till now , keep it up. you rock
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
A clear-cut & very informative explanation. Maximum "Bang for the buck"!
Short and sweet explaination.Thank you
thanks so much for your clear explanation!!!
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
I want to thank you from the core of my heart for explaining such a tedious topic with so simplicity.
superb, very well articulated!!! Thank you.
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?
Funny like Scrum videos always consider things as projects..
We usually sit on feature or platform teams never project based just strings of epics so we measure constantly
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.
Great stuff!!, please upload more videos.
very well explained ..Thanks
Beautifully done!!! It makes so much sense to me.
Outstanding presentation - simple and clear!
You are sooo good at explaining. Thank you so much for this video ♡
Great video. Thanks a lot for sharing!
This was truly a great video. thank you.
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?
It's okay up to a point. I only have a question in first iteration. When you are starting to first iteration of a new product, you gonna need to tell a roughly time that it is going to finish. You cannot say to the team that I have a story but I dont know how many sprints it is gonna take. Have you got answer for this question ?
Great job! Clear and simple!
Outstanding! Congratulations!
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.
Awesome, never seen better elucidation in this topic!
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)?
Nice overview on Agile estimation. Loved the visuals and clear explanations. Thank you!
Awesome. This cant be explained any way better. 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????????
Thank you. This was a useful overview of Agile estimation
Excellent, clear, easy to understand. Many thanks.
thanks for making this digestible
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 :)
Thanks for taking a common topic and making it interesting video. Please add more videos
perfectly Explained , Thanks
It makes alot of sense to me, but this presentation is not taking into cognizance some key technical dependencies or requirements that often occasion the decision to start with stories with easier dependencies first before the much complicated ones ? I cannot wait to get some feedback on this
The best explanation, thanks!
awesome video! GOLD content! thank you!
Excellent explanation 🙌👏👏👏🤩🙏
This explanation could have been perfect if you had used ‘new product development’ examples instead of ‘production work’ with little uncertainty. Dropping the story points and value points into the value/effort matrix would have been even more visually appealing rather than the calculated ratio. Other than that, i couldnt have explained it better... well done!
I will take that onboard for any future videos :)
Excellent - thank you very much
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/
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.
Awesome story drawing👍
Well explained. Common topic with new information :) Thank you.
All Scrum masters should go through this.
That extremely helpful. But please answer this question: How to we input Hours in all of this? If I calculate the team's capacity for the 1st Sprint of 2 weeks and I get total Sprint Hours how do I actually know how quickly each story point is done before having to wait until Sprint 1 is over, then look at Velocity and calculate back to how many hours it was. How do I calculate Hours forward. Should I even bother?
Don’t bother. Just use velocity to plan. Assuming you have a fixed team, it is easy to reverse engineer hours per story point based on velocity. Bu5 since you plan in story points, hours are pretty meaningless.
Good job 👏 👍
No swimming pool? What kind of project is this?
I love this video so much!
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.
Very well explained!
Very good method !
Great work!
Thank you!
This is a great explanation. However, not even a minute into it the presentation defined a story point as a measure of time, which is incorrect. The standard definition of a story point is measurement of "the relative work, risk and complexity of a requirement or story." (PMBOK Guide, 6th Edtion) Linking a story point to a unit of time is misleading and will result in teams taking the easy route by saying 1 story point = 1 hour.
Yep that's the point, thanks for your comment - that was the same what I thought.
Maybe at the beginning with less knowledge you need for 3 SP more time than weeks later when you gained more knowledge or experience. The complexity of 3 SP will be the same but you are maybe faster and are able to produce more output in the same amount of time => velocity goes up.
Never bind time to SP
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..
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.
Voice is very low. The video is really good.
Brilliant!
I still don't get it. It's like estimating distance in miles, then record it as Fahrenheit. During the estimation process, we slip in intimidating words like Fibonacci so people will think we know what we are doing