I am in the process of certifying as a Scrum Master, and my colleague recommended you and your videos specifically. Thank you for making such useful, straightforward and thought-provoking material available to people like me who are just starting out in this field!
Hi Mike -- am I right in understanding that because Story Points track effort, they should not be used to track overall productivity gains within a team, but rather just to facilitate more reliable planning? Can you please recommend any further reading in this sense?
Thanks for explaining the story points so simply. If there is a team who uses SP to estimate the story and calculates the capacity in terms of story points too ( 8 points per person for 2 weeks sprint without any vacation) then is it a right statement for them " Story Estimation is related to Capacity". Looking forward an answer from an expert like you.
Конечно! Story points - это как мирелла для оценки того, сколько усилий требуется для выполнения задачи. Мы учитываем такие вещи, как объем работы, сложность и возможные риски. Относительные значения, которые мы присваиваем каждому элементу, имеют большее значение, чем фактические числа. Учитывая все эти факторы, мы можем дать более точную оценку.
I might be missing something but I dont see the video explaining why story points and why not days or hours? If you say a story point is a function of effort, volume, complexity, risk, uncertainty, that is great. However, that does not mean estimate 2 days does not include all of these. As story point can be function of these, so can be an estimation in days or hours as well. Could you clarify what I am missing?
@@MountainGoatSoftware Hi Mike and thank you for your reply. Is it correct to say "if 1sp = 1day, then 5sp = 5days, 8sp = 8 days etc"? To me that would be wrong but some of my coworkers claim that is correct. To me, it is more correct to say: 1sp = 1day 2sp = 1-2 days 3 sp = 2-5 days 5 sp = 5-8 days etc Same applies if using T-shirt sizes. Is this correct?
@@MountainGoatSoftware Exactly, that is my point as well. That is why I thing it should be more a date range as I suggested above. Thanks for explaining Mike
Hi Mike, I have a question that I'd like to pick your brains on. I'm trying to create a burn-up chart for my team here at [A large video game company]. But as you can imagine, in this domain, there are different disciplines like music, art, design, ux and they all have different tasks that don't always follow the full flow that an engineering task or feature might. Which then in turn makes relative sizing and estimating fairly tricky. For forecasting, would you still try to estimate the tasks together to create one single burn up/down chart including all the multidisciplinary tasks? E.g. a spell for a character in the game, vs a background image vs a sound effect etc.? They all have fairly different workflows. Or some other approach?
Hi Mike, Is Story points still relevant? I am asking because the creator, Ron Jeffries regrets that he did so. I can understand your point but how shall I convey this to my Customer. We as an organization use it internally with Scrum teams but didn't see any value in using it. We have done Time estimation when the Product gets onboarded due to fixed scope and we need to give release plans to our customer based on time estimates. So where is the value here?
Story points are very much still relevant and useful. No one person gets to say they aren't. Their primary benefit is in allowing team members who produce work at different rates to agree on an estimate. A junior and senior dev will never agree on the time something will take. They can, however, agree that this thing will take twice as long as that thing. Story points estimate the size of the project. They can be converted to a release plan using velocity.
Hey Mike, thanks for the video! What's your thoughts on WSJF (Weighted Shortest Job First) and how it relates to Story Points? Sometimes when I've got multiple projects I'm considering I like to use this as a way to help decide on what to do. For anyone reading this and they've never heard of WSJF, you give "Point" values to 4 different criteria and apply the WSJF formula, and whatever the smallest number is, that's the project you begin. *The WSJS formula:* (PROFIT VALUE + TIMING + ENABLER) / SIZE = WSJF . . .
Thanks, interesting.. but 99% of companies IT count on FTE units, so "man day" as costs of every single role change according to the expertise. All the Program/Projects end up on the Division Budget, counted on FTE for cost allocation and accounting. Actually that is the challenge, inside a Scrum team you can have a tester, or achitect and BA that cost by day is different. The questions are: 1. who have the final word on assigning FTE to each actvitiy? as the PO is responsible for the backlog, doe sit include the FTE assignment? 2. how do you balance that each person on the Scrum team is ful y busy to avoid cost losses? 3. How oyu manage a scrum team who is working on some Stories insidea Sprint that doesn't need 2-3 memebers expertise? 4. which technique or method do you use to move from Story points to FTE? 5. Fibonacci numbers are 1, 2, 3, 5, 8, 13 and 21 (most of the videos use 20) why?
Albert, thanks for the detailed comments. To answer all of those questions here would take too long, so I’ll think about a video to address the financial reporting problems you describe. I do talk about why I use a modified Fibonacci sequence in this blog: www.mountaingoatsoftware.com/blog/why-the-fibonacci-sequence-works-well-for-estimating. Hope that helps!
Good video Mike. Thanks. Few queries: 1. How to decide on the base story? 2. Do we need to provide story points to all stories in PB at one go or do sprint wise? 3. How to calculate the size of software in some unit or days initially to get budget approval? Thanks
@@MountainGoatSoftware Thanks Mike. More questions: 1. What is the major research going on in the field of Agile? 2. I believe there is no formal name of the meeting called for the story point estimation, correct? 3. In the beginning of project, as technology and architecture was not clear, so team estimated very high for base story and also estimated high for other stories. But they are able to complete. Based on that velocity is calculated as high say 60 points. But later team estimated the stories correctly but expectation is to meet 60 points, which may be impossible. Then questions raised why. So how this type of situation is handled?
@@MountainGoatSoftware Thanks again. I got your blog on capacity based sprint planning and currently reading the same. 😊 Two last questions: 1. Can we say that story points are nothing but size of the software? If not then why? Then which technique do we use to calculate the software size in agile? 2. In Jira tool, there is a field "Original estimate" in days or hours. So when we are deriving story points then what is the purpose of effort fields in days or hours? Also where and in which meeting we are calculating the hours for a user story? Actually my queries never let me sleep, so pls don't mind. You are really helpful.
@@MountainGoatSoftware i watched your video multiple time. You mentioned that we can use any scale to provide story point. Then how can we calculate size of software? There is no fix standard.
Hi Mike, thanks for explaining this. But if Story Point is function of effort considering risk, uncertainty and complexity then why story point and not person hours or person days? Really want to understand it. For me story point brings conversation to the story and that is very important but I need to understand the logic behind Story Point.
Mike Cohn - I am here because I saw a projects where one story point directly translates into x hours - it somehow didn’t made any sense . Would you help understand ?
@@MountainGoatSoftware If we cant agree on time, how are we supposed to agree on effort? If you are fast at something and I am slow, wouldn't the time difference be equal to the effort difference? My being slow at something is a function of not knowing how to do it, and therefore, my level of effort (and time needed) will cause my estimation (in story points or time) to be higher than yours. If you know how to do something better and faster than I do, you are always going to estimate lower than I will, regardless of whether we are talking about hours or story points.
How to may a story point to a time unit? After all, we need some time unit. For example, for a JIRA, considering everything (volume, complexity, risk, uncertainty), if I give 10 SP. Does it mean 10 hours? 10 days? Iam not clear about it
Great video Mike. Thanks. Can you give a practical example scrum masters could refer to when trying to convince business in organisations reluctant to accept story points as units of measure for complexity?
A dependency does not increase the effort to do the work so it wouldn't impact the estimate. It should, however, be something a team accounts for when _planning_ which should be a different activity from estimating. Typically, a team would plan to get the work from another team in advance of their own work. I will sometimes add a "nag task" to a sprint backlog in those cases--e.g., "Nag other team to give us xyz by Monday."
Hi Mike , I have two queries. we are starting a new team , where we dont have experience Story point from the previous iteration/Sprint , which can be used for the reference .Do you have any tips in that direction .We do have overall team capacity and the Approximately Effort for the Each task /subtask . Second Query we had , The client/Business has been notified with the work End date . whereever as per my understanding if we go by Story point completion . we dont have the end date for any work . .. please suggest .
Nicely explained! The two biggest problems I see with story points are A) people are too inexperienced to adequately consider complexity and uncertainty as you suggest, and B) businesses don’t know how to communicate progress without deadlines, so they translate points to hours at some point. I still think points can be valuable, but with the average software developer career at 7 years, people leave our industry too early to really master estimation as an industry practice. I talked about this in one of my videos about how forecasting impacts agile projects that may help someone. ruclips.net/video/4c7tXGIhavA/видео.html I hope we can find some alternatives that are more realistic considering the anti-agile environment of most companies.
Hey @@carlosbenavides670 that's a great question. As I'm guessing you know every team is different - but the original spirit of story points is to break work up into smaller pieces to commit to less at one time. This helps a team be agile by not committing to more than they can reasonably estimate considering the bad track record we have in the software industry at planning large quantities of work up-front. The end of sprint wasn't really meant to be a deadline - but a goal. Teams that treat it like a deadline often lie about progress, and deliver low quality work when unexpected complexity inevitably unfolds. They don't let their scrum master know this - it all happens behind the scenes if you're an engineer on the ground. To create the safety so that silliness doesn't happen, teams I work with are more successful if sprints are used as a learning opportunity. I talk about this in one of the videos over on my channel, "The Secret of Scrum Nobody Talks About": ruclips.net/video/B_ERfMMSAwY/видео.html
I think a get your point. and I disagree in some of them. I think you assume too much and narrow your view to what you think is the norm. Just something for you to think about: "...deliver low quality work when unexpected complexity inevitably unfolds. " Let's break it into 2 parts, from the end. unexpected complexity inevitably unfolds => As Tech leads, we have ways to minimize this. This should not be the norm, but the exception. deliver low quality work. => Bad Tech Leads (with their devs) deliver "unexpected low quality work". I'll take a look at your video later on :)
Carlos Benavides I can only go off my anecdotal experience since I’m not a researcher. But after being on over 30 projects over my career, it seems to be the norm. Whether I’m the tech lead, an agile coach, or a consultant - companies who treat estimates as commitments eventually devolve into a culture of politics and cease to be a place for innovation and real results. If you’ve worked at places that buck that trend (and have the relationship with people to know their honest opinion) that’s great! I hope more teams get healthy.
Good one Mike. As per my understanding the effort that you are talking about in this video is the hours of effort that is required. Could you please provide you view on the mapping the story point with hours of effort that the story takes. Also could you please put some light on using the Fibonacci series for the estimation.
@@lallu1122 you measure how long it takes your team to execute a story point on average. This is called velocity. You can then take future estimates in story point and multiply by velocity to give a time estimate.
I understand the concept of Story Points, but why can't we just use person hours/person days to estimate a task. Of course we can use complexity, risks, uncertainties to come up with an approximate value. By using this, can't we calculate approximate time to finish tasks better? I just want to understand why story points is a good/better approach over some other approach.
According to Jeff Sutherland's book "Scrum: The Art of Doing Twice the Work in Half the Time" It is because those numbers occur often in nature and so humans are used to them and it's easier to estimate and guess with them.
Thanks for very clearly explaining. I have one request could you explain if there is any way to measure the story point with range of days required to complete the work
Story points are relative and not absolute. But management is been asking me to come up with some formula or measure to tell , what it means by certain story points - how much time it may require ( they are ok to have a range of days ) Major reason of this is team has often missed the release dates which were committed by the TEAM. And it had made lot of issues among stockholders Please share your insights to solve the problem :)
@@b0mazor If it’s just you then stick with days. Story Points are useful when a team needs to agree on an estimate. What a junior and senior dev think of as “one day” will be different. But (generally) the junior and senior can agree, “this will take twice as long as that.” That’s when story points can be useful.
Hi Mike, Nice video. I have a question related to sizing. I am the Scrum master of a team with junior developers. Sometimes they would like to investigate before we can size certain user stories. So I was thinking of implementing spikes in a sprint in order to size the user story in next sprint. Should the spike be sized? If I follow strictly the Scrum guide I shouldn’t since it is not an increment. But then the teams velocity would be lower and therefore the velocity average that we use when we plan the capacity of the team in sprint planning will be affected. Example sprint 1= 30 points sprint=20 pts (due to spikes), should we plan for sprint 3 25 pts or 30 points... maybe in sprint 3 there are no spikes.. Or when you mean uncertainty you mean you also will give more points to the user story due to lack of knowledge? Then The spikes would not be needed..
Any number will do, and since it is a fixed task, you might use it as a parameter... Like, an 8 is how hard (LoE) for the Earth to go 1 iteration... Then you can perhaps think that Mercury uses less than 8 and Saturn more than 8.
I think I know why these are cold story points it's like that fish story that fishermen tell about the fish that got away and The One That Got Away that's what these are these are those things how would you rate that story that that fisherman just told that's all this is basically it's busy work so managers can feel important
Uhh, no. We've actually know for nearly 120 years that time is not a constant. And I'm not sure why a manager (or "manager") would want to play jokes on an employee. Story points are useful in discussions between two team members who produce at different rates. A junior programmer may say something will take a week whereas a senior may say a day. If they argue in days, they will never come to agreement. Those two, who produce at different rates, can agree, however, that the thing will take half as long as some other thing.
Estimating in person days can be a very viable approach for some days. The biggest issue is when the team has members of vastly different abilities--what one person can do in a day can be very different from what another person can do in a day. Story points are meant to solve that problem.
Have exam in two days time and watching this video helped me to grasp this concept thanks for uploading.
You're welcome. Good luck!
Excellent explanation, crisp, brisk and clear
I am in the process of certifying as a Scrum Master, and my colleague recommended you and your videos specifically. Thank you for making such useful, straightforward and thought-provoking material available to people like me who are just starting out in this field!
My pleasure. I look forward to continuing to learn from you.
One of the best videos on the topic. Explained with great clarity. Keep it up👍
Hi Mike -- am I right in understanding that because Story Points track effort, they should not be used to track overall productivity gains within a team, but rather just to facilitate more reliable planning? Can you please recommend any further reading in this sense?
Thanks for explaining the story points so simply. If there is a team who uses SP to estimate the story and calculates the capacity in terms of story points too ( 8 points per person for 2 weeks sprint without any vacation) then is it a right statement for them " Story Estimation is related to Capacity". Looking forward an answer from an expert like you.
Very clearly explained.Thank You .
I was sure story points were created to make it harder to calculate the actual effort and therefore the cost of delivering a piece of work.
awesome video Mike
Thanks, Sean! I appreciate it.
You're the GOAT, thanks a ton
Thank you!
Конечно! Story points - это как мирелла для оценки того, сколько усилий требуется для выполнения задачи. Мы учитываем такие вещи, как объем работы, сложность и возможные риски. Относительные значения, которые мы присваиваем каждому элементу, имеют большее значение, чем фактические числа. Учитывая все эти факторы, мы можем дать более точную оценку.
I might be missing something but I dont see the video explaining why story points and why not days or hours? If you say a story point is a function of effort, volume, complexity, risk, uncertainty, that is great. However, that does not mean estimate 2 days does not include all of these. As story point can be function of these, so can be an estimation in days or hours as well. Could you clarify what I am missing?
@@MountainGoatSoftware Hi Mike and thank you for your reply. Is it correct to say "if 1sp = 1day, then 5sp = 5days, 8sp = 8 days etc"?
To me that would be wrong but some of my coworkers claim that is correct.
To me, it is more correct to say:
1sp = 1day
2sp = 1-2 days
3 sp = 2-5 days
5 sp = 5-8 days
etc
Same applies if using T-shirt sizes.
Is this correct?
@@MountainGoatSoftware Exactly, that is my point as well. That is why I thing it should be more a date range as I suggested above. Thanks for explaining Mike
Hi Mike, I have a question that I'd like to pick your brains on. I'm trying to create a burn-up chart for my team here at [A large video game company]. But as you can imagine, in this domain, there are different disciplines like music, art, design, ux and they all have different tasks that don't always follow the full flow that an engineering task or feature might. Which then in turn makes relative sizing and estimating fairly tricky. For forecasting, would you still try to estimate the tasks together to create one single burn up/down chart including all the multidisciplinary tasks? E.g. a spell for a character in the game, vs a background image vs a sound effect etc.? They all have fairly different workflows. Or some other approach?
Hi Mike,
Is Story points still relevant? I am asking because the creator, Ron Jeffries regrets that he did so. I can understand your point but how shall I convey this to my Customer. We as an organization use it internally with Scrum teams but didn't see any value in using it. We have done Time estimation when the Product gets onboarded due to fixed scope and we need to give release plans to our customer based on time estimates. So where is the value here?
Story points are very much still relevant and useful. No one person gets to say they aren't. Their primary benefit is in allowing team members who produce work at different rates to agree on an estimate. A junior and senior dev will never agree on the time something will take. They can, however, agree that this thing will take twice as long as that thing. Story points estimate the size of the project. They can be converted to a release plan using velocity.
Hey Mike, thanks for the video! What's your thoughts on WSJF (Weighted Shortest Job First) and how it relates to Story Points? Sometimes when I've got multiple projects I'm considering I like to use this as a way to help decide on what to do. For anyone reading this and they've never heard of WSJF, you give "Point" values to 4 different criteria and apply the WSJF formula, and whatever the smallest number is, that's the project you begin.
*The WSJS formula:*
(PROFIT VALUE + TIMING + ENABLER) / SIZE = WSJF
.
.
.
Hi Mike
Does Agile talk about Estimation?? where this Agile estimation of Story Point came from ?? I didnt get a clear picture of its origin??
Thanks, interesting.. but 99% of companies IT count on FTE units, so "man day" as costs of every single role change according to the expertise. All the Program/Projects end up on the Division Budget, counted on FTE for cost allocation and accounting. Actually that is the challenge, inside a Scrum team you can have a tester, or achitect and BA that cost by day is different.
The questions are:
1. who have the final word on assigning FTE to each actvitiy? as the PO is responsible for the backlog, doe sit include the FTE assignment?
2. how do you balance that each person on the Scrum team is ful y busy to avoid cost losses?
3. How oyu manage a scrum team who is working on some Stories insidea Sprint that doesn't need 2-3 memebers expertise?
4. which technique or method do you use to move from Story points to FTE?
5. Fibonacci numbers are 1, 2, 3, 5, 8, 13 and 21 (most of the videos use 20) why?
Albert, thanks for the detailed comments. To answer all of those questions here would take too long, so I’ll think about a video to address the financial reporting problems you describe. I do talk about why I use a modified Fibonacci sequence in this blog: www.mountaingoatsoftware.com/blog/why-the-fibonacci-sequence-works-well-for-estimating. Hope that helps!
Good video Mike. Thanks. Few queries:
1. How to decide on the base story?
2. Do we need to provide story points to all stories in PB at one go or do sprint wise?
3. How to calculate the size of software in some unit or days initially to get budget approval?
Thanks
@@MountainGoatSoftware Thanks Mike. More questions:
1. What is the major research going on in the field of Agile?
2. I believe there is no formal name of the meeting called for the story point estimation, correct?
3. In the beginning of project, as technology and architecture was not clear, so team estimated very high for base story and also estimated high for other stories. But they are able to complete. Based on that velocity is calculated as high say 60 points. But later team estimated the stories correctly but expectation is to meet 60 points, which may be impossible. Then questions raised why. So how this type of situation is handled?
@@MountainGoatSoftware Thanks again. I got your blog on capacity based sprint planning and currently reading the same. 😊
Two last questions:
1. Can we say that story points are nothing but size of the software? If not then why? Then which technique do we use to calculate the software size in agile?
2. In Jira tool, there is a field "Original estimate" in days or hours. So when we are deriving story points then what is the purpose of effort fields in days or hours? Also where and in which meeting we are calculating the hours for a user story?
Actually my queries never let me sleep, so pls don't mind. You are really helpful.
@@MountainGoatSoftware i watched your video multiple time. You mentioned that we can use any scale to provide story point. Then how can we calculate size of software? There is no fix standard.
Hi Mike, Why cant the numbers be linear (1,2,3,4,5,6,7...) when estimating? I see numbers are 0,1,2,3,5,8,13... as per Fibonacci series
@@MountainGoatSoftware Thank a lot for your explanation. Really appreciate it.
Hi Mike, thanks for explaining this. But if Story Point is function of effort considering risk, uncertainty and complexity then why story point and not person hours or person days?
Really want to understand it. For me story point brings conversation to the story and that is very important but I need to understand the logic behind Story Point.
@@MountainGoatSoftware true. I have read this in your book and thanks for highlighting this. I think without this point story point is incomplete.
Mike Cohn - I am here because I saw a projects where one story point directly translates into x hours - it somehow didn’t made any sense . Would you help understand ?
@@karthikj8969 yes, you're correct in assuming that doesn't make sense.
@@MountainGoatSoftware If we cant agree on time, how are we supposed to agree on effort? If you are fast at something and I am slow, wouldn't the time difference be equal to the effort difference? My being slow at something is a function of not knowing how to do it, and therefore, my level of effort (and time needed) will cause my estimation (in story points or time) to be higher than yours. If you know how to do something better and faster than I do, you are always going to estimate lower than I will, regardless of whether we are talking about hours or story points.
Whoever does your graphics for these videos is really good. Very clean, and easy to follow.
so whats a the story points? some complex function of uncertain efforts, risks and othe moving parts? and how then should we use them?
I answer all of those questions here: www.mountaingoatsoftware.com/blog/what-are-story-points
How to may a story point to a time unit? After all, we need some time unit. For example, for a JIRA, considering everything (volume, complexity, risk, uncertainty), if I give 10 SP. Does it mean 10 hours? 10 days? Iam not clear about it
Great, story points represents complexity of the work but can a 1 story point story be completed in 5 days?
Great video Mike. Thanks. Can you give a practical example scrum masters could refer to when trying to convince business in organisations reluctant to accept story points as units of measure for complexity?
So besides 1. Sprint Planning, and 2. Release Forecasting, are story points used for anything else?
Well explained
Hi Mike,Iam Raje. How can we estimate for external dependencies..Do we need to consider this as we cant predict for external impediments.Please advice
A dependency does not increase the effort to do the work so it wouldn't impact the estimate. It should, however, be something a team accounts for when _planning_ which should be a different activity from estimating. Typically, a team would plan to get the work from another team in advance of their own work. I will sometimes add a "nag task" to a sprint backlog in those cases--e.g., "Nag other team to give us xyz by Monday."
Hi Mike , I have two queries. we are starting a new team , where we dont have experience Story point from the previous iteration/Sprint , which can be used for the reference .Do you have any tips in that direction .We do have overall team capacity and the Approximately Effort for the Each task /subtask . Second Query we had , The client/Business has been notified with the work End date . whereever as per my understanding if we go by Story point completion . we dont have the end date for any work . .. please suggest .
My product owner asks where to buy a clock that shows story points.
🧐😁😁😁
Nicely explained!
The two biggest problems I see with story points are A) people are too inexperienced to adequately consider complexity and uncertainty as you suggest, and B) businesses don’t know how to communicate progress without deadlines, so they translate points to hours at some point.
I still think points can be valuable, but with the average software developer career at 7 years, people leave our industry too early to really master estimation as an industry practice. I talked about this in one of my videos about how forecasting impacts agile projects that may help someone.
ruclips.net/video/4c7tXGIhavA/видео.html
I hope we can find some alternatives that are more realistic considering the anti-agile environment of most companies.
Can you elaborate more on point B?
Like, if you get an PIB into a sprint, then you already got your deadline.
Hey @@carlosbenavides670 that's a great question.
As I'm guessing you know every team is different - but the original spirit of story points is to break work up into smaller pieces to commit to less at one time.
This helps a team be agile by not committing to more than they can reasonably estimate considering the bad track record we have in the software industry at planning large quantities of work up-front.
The end of sprint wasn't really meant to be a deadline - but a goal. Teams that treat it like a deadline often lie about progress, and deliver low quality work when unexpected complexity inevitably unfolds.
They don't let their scrum master know this - it all happens behind the scenes if you're an engineer on the ground.
To create the safety so that silliness doesn't happen, teams I work with are more successful if sprints are used as a learning opportunity. I talk about this in one of the videos over on my channel, "The Secret of Scrum Nobody Talks About":
ruclips.net/video/B_ERfMMSAwY/видео.html
I think a get your point.
and I disagree in some of them. I think you assume too much and narrow your view to what you think is the norm.
Just something for you to think about:
"...deliver low quality work when unexpected complexity inevitably unfolds. "
Let's break it into 2 parts, from the end.
unexpected complexity inevitably unfolds => As Tech leads, we have ways to minimize this. This should not be the norm, but the exception.
deliver low quality work. => Bad Tech Leads (with their devs) deliver "unexpected low quality work".
I'll take a look at your video later on :)
Carlos Benavides I can only go off my anecdotal experience since I’m not a researcher. But after being on over 30 projects over my career, it seems to be the norm. Whether I’m the tech lead, an agile coach, or a consultant - companies who treat estimates as commitments eventually devolve into a culture of politics and cease to be a place for innovation and real results. If you’ve worked at places that buck that trend (and have the relationship with people to know their honest opinion) that’s great! I hope more teams get healthy.
@@HealthyDev
" I’m not a researcher."
:(
Are you sure you are in the right industry Sr?
Good one Mike. As per my understanding the effort that you are talking about in this video is the hours of effort that is required. Could you please provide you view on the mapping the story point with hours of effort that the story takes. Also could you please put some light on using the Fibonacci series for the estimation.
The whole idea of story points is that they are decoupled from time.
@@bartholomewtott3812 if you decouple, then how to give estimates to management? We need some measurable time (XX days/hours)
@@lallu1122 you measure how long it takes your team to execute a story point on average. This is called velocity. You can then take future estimates in story point and multiply by velocity to give a time estimate.
Brilliant
I understand the concept of Story Points, but why can't we just use person hours/person days to estimate a task. Of course we can use complexity, risks, uncertainties to come up with an approximate value. By using this, can't we calculate approximate time to finish tasks better? I just want to understand why story points is a good/better approach over some other approach.
Well explained sir
Hey Mike, one common question asked by team members. Why are we using fibonacci series for estimation? Can you explain it in simple way
According to Jeff Sutherland's book "Scrum: The Art of Doing Twice the Work in Half the Time" It is because those numbers occur often in nature and so humans are used to them and it's easier to estimate and guess with them.
Thanks for very clearly explaining. I have one request could you explain if there is any way to measure the story point with range of days required to complete the work
Story points are relative and not absolute. But management is been asking me to come up with some formula or measure to tell , what it means by certain story points - how much time it may require ( they are ok to have a range of days )
Major reason of this is team has often missed the release dates which were committed by the TEAM. And it had made lot of issues among stockholders
Please share your insights to solve the problem :)
Great explanation.
0
I dont get this. I do this rn but with time. I tell my boss 1 day work, 2 day work, 1/2 day work.
@@b0mazor If it’s just you then stick with days. Story Points are useful when a team needs to agree on an estimate. What a junior and senior dev think of as “one day” will be different. But (generally) the junior and senior can agree, “this will take twice as long as that.” That’s when story points can be useful.
Hi Mike,
Nice video. I have a question related to sizing. I am the Scrum master of a team with junior developers. Sometimes they would like to investigate before we can size certain user stories. So I was thinking of implementing spikes in a sprint in order to size the user story in next sprint. Should the spike be sized?
If I follow strictly the Scrum guide I shouldn’t since it is not an increment.
But then the teams velocity would be lower and therefore the velocity average that we use when we plan the capacity of the team in sprint planning will be affected.
Example sprint 1= 30 points sprint=20 pts (due to spikes), should we plan for sprint 3 25 pts or 30 points... maybe in sprint 3 there are no spikes..
Or when you mean uncertainty you mean you also will give more points to the user story due to lack of knowledge? Then The spikes would not be needed..
One quick query, does story points efforts include testing team estimates as well ?
Great!
Om shanti
I wonder when we start using Story Points to count the time that the Earth takes to revolve around the Sun...
Any number will do, and since it is a fixed task, you might use it as a parameter...
Like, an 8 is how hard (LoE) for the Earth to go 1 iteration...
Then you can perhaps think that Mercury uses less than 8 and Saturn more than 8.
I think I know why these are cold story points it's like that fish story that fishermen tell about the fish that got away and The One That Got Away that's what these are these are those things how would you rate that story that that fisherman just told that's all this is basically it's busy work so managers can feel important
Given that managers aren’t involved in estimating or using story points, I have no idea why they’d make them feel important.
This is what happens when "managers" have too much time on their hands. Time is a constant and these are all jokes on the employee
Uhh, no. We've actually know for nearly 120 years that time is not a constant. And I'm not sure why a manager (or "manager") would want to play jokes on an employee.
Story points are useful in discussions between two team members who produce at different rates. A junior programmer may say something will take a week whereas a senior may say a day. If they argue in days, they will never come to agreement. Those two, who produce at different rates, can agree, however, that the thing will take half as long as some other thing.
Or just say 2 days of work 😂
Estimating in person days can be a very viable approach for some days. The biggest issue is when the team has members of vastly different abilities--what one person can do in a day can be very different from what another person can do in a day. Story points are meant to solve that problem.