What Are Story Points And Why Do We Use Them In Agile?
Vložit
- čas přidán 28. 05. 2024
- What are story points and how do agile teams estimate using story points? Find out in this video.
Take a video course from Mountain Goat Software: www.mountaingoatsoftware.com/...
You can read the original post here: www.mountaingoatsoftware.com/...
Inside "What Are Story Points and Why Do We Use Them in Agile"
00:00 Story Points Defined
00:12 How Story Points Work
00:20 Story Points are Relative
00:34 Ratios Matter
00:49 Estimate the Effort
1:15 Amount of Work & Effort
2:15 Risk/Uncertainty & Effort
One of the best videos on the topic. Explained with great clarity. Keep it up👍
Have exam in two days time and watching this video helped me to grasp this concept thanks for uploading.
You're welcome. Good luck!
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.
Excellent explanation, crisp, brisk and clear
Very clearly explained.Thank You .
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
.
.
.
awesome video Mike
Thanks, Sean! I appreciate it.
Конечно! Story points - это как мирелла для оценки того, сколько усилий требуется для выполнения задачи. Мы учитываем такие вещи, как объем работы, сложность и возможные риски. Относительные значения, которые мы присваиваем каждому элементу, имеют большее значение, чем фактические числа. Учитывая все эти факторы, мы можем дать более точную оценку.
Well explained
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?
Brilliant
Well explained sir
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.
Great explanation.
0
Whoever does your graphics for these videos is really good. Very clean, and easy to follow.
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!
Great!
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 , 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 .
Great, story points represents complexity of the work but can a 1 story point story be completed in 5 days?
So besides 1. Sprint Planning, and 2. Release Forecasting, are story points used for anything else?
My product owner asks where to buy a clock that shows 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.
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.
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
Does Agile talk about Estimation?? where this Agile estimation of Story Point came from ?? I didnt get a clear picture of its origin??
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
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.
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
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.
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.
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.
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..
How does that relate to mathematics and ordinal numbers?
I'm not sure why you keep asking but as I've said to you previously I recommend estimating story points on a ratio scale so they are not ordinals.
@@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
One quick query, does story points efforts include testing team estimates as well ?
Om shanti
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.
czcams.com/video/4c7tXGIhavA/video.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":
czcams.com/video/B_ERfMMSAwY/video.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?
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.