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!
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.
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?
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
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!
Конечно! Story points - это как мирелла для оценки того, сколько усилий требуется для выполнения задачи. Мы учитываем такие вещи, как объем работы, сложность и возможные риски. Относительные значения, которые мы присваиваем каждому элементу, имеют большее значение, чем фактические числа. Учитывая все эти факторы, мы можем дать более точную оценку.
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 . . .
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, 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.
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.
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.
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
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."
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.
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 .
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.
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 :)
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..
@@MikeCohn Hm, I did not see any previous answer Mike (maybe disqus had some issues), so if that's the case then we have an agreement here. Thus such values need to be calibrated to time in order to be cardinal numbers.
@@MightyMethods Disqus seems to have gone quite down hill the past few years. I often tell teams that individuals can think in time but should speak in points. So, I think, "This will take me 8 hours, and that's like....this other backlog item. We called that item 5 points so this one is also 5 points." If we speak in time then we have all the traditional problems of person-hours. It may take you 4 hours to do but it will take me 8. So then we argue 4 vs. 8. But if we speak in points (by comparison to done items) those problems go away.
@@MikeCohn hehe, so you've replied to my post yet I cannot see it, indeed the service went downhill :) I can agree with you here. I just use a different way of calibration - I model points as categories, assign ranges of time to them and after some time we do the recalibration based on historical data. At least it gives some amount of knowledge about time-ranges and when to start escalating stuff given the % of time used according to a range. It's not shoved down anyone's throat, yet up to this point, I have not met any objections. So it's not e.g. 5 = hardcoded n amount of time, it's rather a scale of up to n amount of time considering all previous categories. So 1 = up to n amount of time, 3 - up to n amount of time >1 yet
@@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.
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. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-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": ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-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.
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.
