5

As far as I'm aware there's no definition of Story Points and how to compare them. Each person in a team may have his personal understanding of the correlation between an effort and Story Points. Isn't Story Points estimation just a fallacy?

Isn't it just a belief. For example, it's assumed that all tasks have a specific property - the difficulty, the amount of effort. But they maybe don't. And even if they do, it is just a belief that we can adequately estimate it as a number. The amount of time a task will take is intrinsically indeterminate.

For example: During Planning Poker all teammembers agree that a PBI should be estimated as 10 Story Points and they go to the next PBI. This 10 Story Point estimation actually means nothing because everybody understands 10 Story Points differently (different amount of effort, time, risks).

I just want reliable arguments (a research, comprehensive surveys) that SP is really a tool, and not just a belief.

Chris Brettini
  • 970
  • 9
  • 19
  • 8
    The question and the comments on the answers makes it seem like you just want to argue. Story points have no fixed tie to time or money. Consistent teams working in the same context often observe a strong correlation after they've been working together for a period of time. The technique was designed this way. It's just a tool you can use or not. – Daniel Jan 27 '20 at 02:10
  • I think the same @Daniel. – Tiago Martins Peres Jan 27 '20 at 07:01
  • @Daniel No, I just want reliable arguments that SP is really a TOOL, and not just a BELIEF. – Chris Brettini Jan 27 '20 at 07:43
  • 1
    Chris Brettini you got arguments! Thing is you have a BELIEF that only your BELIEF is right and you cannot provide reliable arguments for that. – Tiago Martins Peres Jan 27 '20 at 11:23
  • 3
    The request for information is good - although I rather thought this had been addressed before on PM:SE. The distinction between "tool" and "belief" seems like a false dichotomy and seems to be deployed in service of a rhetorical goal. – MCW Jan 27 '20 at 16:00
  • 1
    Yes, i also think what Chris Brettini wants was already answered here. – Tiago Martins Peres Jan 27 '20 at 16:04
  • 1
    I'm not sure what a belief is defined as. What Taigo posted may help. Also, in one of Mike Cohn's keynotes he talks about his organization running multiple estimations methods against each other and story points came out on top as most useful. Hundreds, if not thousands of teams use them successfully every day. They are a well-priced tool, regardless of published studies. They do, however, challenge many traditional assumptions about estimation, so you can't use them like you use hours. – Daniel Jan 27 '20 at 20:21
  • I've heard similar arguments from countless developers who just didn't like to do estimates. They'd come up with the most complex points to justify the idea that any kind of estimation is flawed and, therefore, useless. However, linking SP to religion is a new one to me. Kudos for the criativity. – Daniel Jan 28 '20 at 19:25
  • I can't think of a single task that doesn't have difficulty or effort attached to it. Could you provide some examples? – Daniel Jan 28 '20 at 19:27
  • 1
    As written, this question is too open-ended. Entire books have been written on the subject of empirical control theory and estimation techniques, so this question is too broad. It's also inviting debate, which is a sort of subjective, list-generating question format that is considered off-topic here. There's a valid underlying question, but without heavy editing it's likely to be closed shortly as not in line with question-asking guidance from our Help Center. – Todd A. Jacobs Jan 30 '20 at 14:54
  • Based on the extended back-and-forth in the comments, I’ll stand by my previous statement that this question is too broad and too open-ended. I think there’s a valid question in here, but PMSE is designed for canonical Q&A, not debates. However, the community can re-open this question at their discretion after some judicious editing and comment clean-up. – Todd A. Jacobs Feb 04 '20 at 11:58

5 Answers5

15

Story points are a relative measure of effort rather than an absolute one. However, each member of the team should have the same understanding of the size of a points estimate. A common understanding is achieved when the team estimates repeatedly together and when they agree common baseline stories against which to measure. This is really no different to estimating in hours or days where people also measure things against remembered baselines. Planning poker is one way of making sure that teams have a common understanding of the size of items.

Relative estimation with story points has a few advantages over absolute estimation. It seems that many people come up with more accurate relative estimates than absolute ones. Velocity, as measured by story points completed per iteration, is an evidence-based measure whereas hours based estimates tend to be more subjective. If you measure things in hours then you can still retrospectively measure how many estimated "hours" you actually completed but that will inevitably differ from actual hours of work put in, so the reality is that "hours" tend to become a relative measure too.

nvogel
  • 6,295
  • 1
  • 9
  • 28
  • Thank you! The advantage of hours is that everybody undestands them. How do we know that we have the shared understanding of story points? Should we include risks in SP-estimation? How to estimate complexity in SPs? – Chris Brettini Jan 26 '20 at 10:40
  • 5
    You know that you have a shared understanding of story points estimates the same way you know that you have a shared understanding of hours estimates: by agreeing them as a group. Team estimating techniques like Poker or Bockman's Game ensure that if anyone has a difference of opinion then that difference is obvious to everyone and the group has a chance to agree a consensus. – nvogel Jan 26 '20 at 10:53
  • Your argument has a flaw - you already assume that every body has a shared understanding. Assuming this being the case you then describe the Planning Poker process. – Chris Brettini Jan 26 '20 at 14:19
  • Planning Poker is about achieving a shared estimate for a PBI - not about achieving a shared understanding of what 1 SP means. – Chris Brettini Jan 26 '20 at 14:22
  • It amounts to the same thing. If the team agrees that story X amounts to 4 points then they "agree" that 1 point is something that is one quarter of X. The unit of measure isn't so important. What matters is that they can agree on a figure and then use that figure to measure the team's velocity. – nvogel Jan 26 '20 at 15:23
  • What is your actual concern? The team should decide how they want to measure estimates. If the team is happier defining the estimates as hours and not points then that's OK. Many people do find that points work out for them but it's not necessarily right for everyone. – nvogel Jan 26 '20 at 15:25
  • I'd like reliable estimate approach to plan a completion date or dates of releases and the Story Points just don't give me these information. – Chris Brettini Jan 26 '20 at 18:21
  • 1
    @ChrisBrettini I often start with 8 points = what can be done in a day, but it doesn't matter. *Your first few iterations will be wrong, but increasingly less wrong* as people adjust their estimates based on data. Tried to do 40 points last iteration, got 20 done, next iteration's capacity is 20. Your iterations should be short, a week or two, for fast feedback and correction. Daily tracking of task completion with burndown charts will quickly tell you if you're on track or not. This leaves nowhere to hide bad estimates. Long term estimation is an advanced topic. – Schwern Jan 26 '20 at 23:03
  • @ChrisBrettini In sum, story points, and associated practices, are about coming to understand your short term capacity, building your ability to accurately estimate the cost of tasks, and knowing when you're off the rails. Only once you have that down, when you can regularly hit your mark for an iteration's worth of work, can you then begin making accurate long term estimates. You can't skip that foundational step. – Schwern Jan 26 '20 at 23:15
12

Let's be serious, people don't usually care how you do estimates. What they care about is how much it takes and/or how much it costs. Time and money. That's what they want. The estimates is just something that helps you answer those questions. It doesn't matter what you use for estimations as long as people can get back a time or money value. It can be estimating directly in hours, or man days, or it can be story points, T-shirt sizes, puppies or vegetables. Nobody cares. Seriously now. It's about time and money.

So you need to have a way to convert from an estimation to time and money, right?

Everyone understands what time is. Everyone understands what money is. And we like to think about them as absolute. One hour is one hour. Ten bucks is ten bucks. But not really. They mean different things to different people. If I am rich and you are poor, ten dollars for me might be useless but for you might be difference in having food on the table or not. If I am a busy person and you are not, then one hour for me means a lot and I use it wisely, while for you it might mean spending it online whatching cat videos on YouTube. Although we perceive them as absolutes, they are not.

From the discussions on the other answers I see that you are asking why not estimate in hours directly instead of story points, since story points are abstract and not absolutes. Everyone understands one hour, but story points mean different things for different people, right? But from what I said above, you see story points are not so different than hours. They mean different things for different people. One hour of development for a senior developer doesn't mean the same thing as one hour of development for a junior developer. The senior can build an entire feature in one hour, the junior might use that hour to figure out how exactly to approach the feature. If the senior developer estimates a feature to take one hour, that estimation is subjective. It depends a lot on skills. The senior will build feature F in one hour, but the junior might take four hours to build the same feature. So what good is a one hour estimate for feature F if it will have to be the junior who needs to work on it? (if the senior developer is unavailable for example).

Estimating in hours is a way to lie to yourself and give you false confidence. You understand hours, so when you estimate a project and get back 1078.65 hours then you have some absolute information there, right? You know what you are dealing with. But you don't. Software development doesn't work like that. That's why we are no longer doing Waterfall all over the place but instead trying to be more Agile. There is a lot of complexity in building software, there is a lot of effort that goes into building the right thing, and a lot of risks. Hour estimations don't reflect these and thinking hours are absolutes is simply delusional. History has shown us that. People suck at estimating, and they suck at attaching hours to those estimates. But it seems we can better estimate things relative to each other. If you have two features, you can estimate pretty well which one is larger than the other, thus which one will need more effort or take more time.

Story points are a way to highlight the difference in sizes between features. A 5 SP feature is more than a 3 SP feature, and less than a 8 SP feature. People might not agree that one hour or ten dollars are the same for everyone because a lot of subjective things influence that, but they can agree that one feature is more complex than another. A 5 SP story is a 5 SP story for both the senior developer and the junior developer. It might take the senior one hour, and the junior four hours to build it, but that doesn't change the fact that in relation to the things they both worked on so far, this is a 5.

Initially people have different understandings about what a 5 is. The senior might think 5 is easy, the junior might think 5 is hard. So when estimating you will get different values for the same feature. But there is a discussion. People dissect the feature and explain why they think it's a 5 or a 1 or a 13 or whatever. In time they figure out, relative to the other features, what is a 5 and a 1 and a 13. It doesn't matter how they subjectively reached that number, relatively speaking they learn to attach the same numbers to similar sized features. Once this happens people will know how much to pull into the sprint and the velocity will start to become relevant. Then you can attach hours to the story points per team as you know how much they can deliver per sprint. But just remember that it will still not be an absolute. There isn't a coincidence why you use Fibonacci to estimate. The higher the SPs, the higher the unknown. In fact, it's not even Fibonacci. A Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, but most planning poker cards are 1, 2, 3, 5, 8, 13, 20, 40, 100. Things get rounded of. The number 89 is absolute, 100 is an approximation. Does it really matter it's an 89 or a 90 or a 95? It makes no difference. It's a lot. So just say 100 and call it a day.

Enough rambling... to get back to your question. The definition of a SP is that it's an abstract measure for the difficulty of a feature and the effort needed to build it. With time, the people in the team figure out what SPs mean for them (this is why, for example, you can't compare story points of one team with the story points of another; 10 SP in one team might mean 40 SPs in another).

See also if this provides extra insight: Why use story points instead of hours for estimating?

Bogdan
  • 15,216
  • 27
  • 48
  • Thank you very much for a detailed answer! But it's still just a belief. For example, you assume that there's such a thing as a difficulty of a task/feature. How do you know that such a thing exist at all? You are sure that all tasks have a specific property - the difficulty. But they maybe don't. And even if they do, it is just a belief that we can adecuately estimate it as a number. – Chris Brettini Jan 26 '20 at 14:44
  • 2
    All features have difficulty and effort needed to build them. That's not a belief. That's just how it is. Things can be easy to do, or hard to do. Things can take a small or a large amount of time to be done. And all things carry risks. When you estimate, you take all these factors into account, no matter if you estimate in hours or in SPs. I didn't quite understood your comment, but the point with the SPs is not to adequately estimate the difficulty as a number. You should consider SPs as boxes in which you can put your features. Smaller boxes, larger boxes, etc. All estimations are... – Bogdan Jan 26 '20 at 16:38
  • 2
    ... most likely wrong. When you use SPs to estimate, the team discusses the work enough to figure out, understand, and agree in which which box a feature should go into. Like many things in Agile, SP estimation is "just enough" estimation to understand the effort needed (i.e. similar effort as other similar features from the past). A 5 SP feature doesn't mean that the 5 is accurate, it just identifies the box with 5 written on it. You can later figure out time for SPs depending on how many SPs the team delivers per sprints. Estimating directly in hours gives you false absolutes... – Bogdan Jan 26 '20 at 16:38
  • 1
    ... that trick you into thinking that you get palpable useful information out of the estimate, but in fact you don't. If you estimate something as 10 hours and it actually takes 11 hours to do, then you are late on your work. If a 5 SP feature takes 10 hours or 11 hours to do, then that's how much it took. You are not late. That's just how 5 SPs translated to hours. After a few sprints, a few rounds of SP estimations, a few values of velocity, you can get an idea on how much things take. But nothing is absolute when it comes to estimates. SPs better express that fact than hours could do. – Bogdan Jan 26 '20 at 16:38
  • What is the use of SPs? Are they used for a Sprint Planning or for planning a large amount of work (for example Epics)? – Chris Brettini Jan 26 '20 at 18:10
  • The team uses SPs to figure out how much work they can pull into the sprint. Once you have the team velocity for a number of sprints, you can extrapolate how much other work will take, like epics or even the entire backlog. If for example you went and estimated your whole backlog at 1000 SPs, and the team's velocity is on average 100 SPs, then you can assume you can finish all PBIs in at least 10 sprints (I say at least, and not exactly 10, because the longer you look ahead, the more uncertainty and risk is involved) – Bogdan Jan 26 '20 at 19:08
  • Well, how do you estimate the whole epic? You can quickly estimate something small, observable, something that you understand how to do. Epic is pretty large, estimating an Epic gives you a large estimation error. Instead of 10 sprints it may take 30 sprints - what is the use of this estimation? I'm asking this because I'm still unsure how SPs can be useful at all. – Chris Brettini Jan 26 '20 at 19:16
  • Fundamentally, an epic is a very large user story that contains other user stories. You cannot work on an epic directly, because it isn't properly detailed. You have to split it into smaller user stories. That's the purpose of the refinement meeting, for example. The team discusses the epic, creates user stories with the appropriate detail, and estimates each story. The epic SPs are then the sum of all the user stories SPs. With any kind of estimations, SPs included, if you want better results you need to split things into smaller pieces, otherwise you have a larger estimation error indeed. – Bogdan Jan 26 '20 at 19:48
  • OK, so we only use SPs for short-term planning, when we have work decomposed into small parts. We don't use SPs and quick planning poker to estimate the completion date of a project. It seems to me that using SPs is just a matter of tatste. – Chris Brettini Jan 26 '20 at 20:23
  • @DJClayworth: Poor choice of words. What I meant was people don't care how you do estimates. Thanks for bringing it to my attention. People usually expect a time value from all estimates. Even your comment reinforces what I'm saying. You say "next month's release" and "ready in time". But even the initial wording holds true. If developers come to you with an effort estimate of 13 story points, do you care or do you want a duration instead? When you have a duration is then your tendency to try to reduce it if you don't like how much something takes? Besides all the things that... – Bogdan Jan 27 '20 at 09:02
  • 1
    ... were said on this post, an advantage of estimating in SPs is that upper management has less room for messing with the estimates. If developers say 10 days, some might be tempted to try to pressure developers into giving a less value ("Can't you guys make it in 8 days? It's really important, it's needed for such and such, bla bla bla"). If something is 5 SPs, you can't say "Can you make it a 3 SP?" because you can't decrease the actual difficulty of something the same way you can do with decreasing the time you work on it. – Bogdan Jan 27 '20 at 09:02
  • Long answer but it is really worth reading it! – holzkohlengrill Feb 19 '20 at 11:53
5

Each person in a team may have his personal understanding of the correlation between an effort and Story Points.

Initially, in a new team, that may be true. That is why an estimation based on Story Points is more than each team member just giving a number and then taking the lowest/highest/average/whatever as the final estimate.

When doing a Story Point estimation, that should also include a discussion in which the team members can explain what they considered when coming to their points value. It is important that at least the people with the highest and lowest estimates a heard, because they are likely to have specific insights into the topic at hand. This can also include insights into risks and/or uncertainties associated with the work item at hand.

Through these discussions, the team members will also get a more common understanding of the combination of effort, complexity and risk that goes into a Story Point.

To underline that estimation is not an exact science and to avoid endless debates if a work item should be 40 or 41 points, estimation techniques like planning poker (that are commonly used to estimate story points) have a granularity of estimates that can be given that increases with the size of the estimates themselves.

Bart van Ingen Schenau
  • 2,795
  • 13
  • 19
  • How do they come to a common understanding of risks? Risks estimation depends on personal experince. Why should we bother ourself with these obfuscated SP instead of just using hours? – Chris Brettini Jan 26 '20 at 10:42
  • 1
    @ChrisBrettini, how do you gain experience in estimating (end recognizing) risks? I hope not exclusively from hitting your nose, but also from others who can point them out before you hit your nose. And that is where the discussions come into play, because that is where someone can point out the risk to the other team members. – Bart van Ingen Schenau Jan 26 '20 at 11:00
  • 1
    @ChrisBrettini The team comes to a common understanding by experience. The longer a team exists as a team, the more their own personal ideas of what a story point is worth will tend to sync up. When you change the members of a team, there will be a period of adjustment where their individual estimates differ more widely, and they have to discuss and agree on which number to use. Over time, they'll start to suggest the same numbers, they'll require less discussion, and their velocity of points per sprint will become more consistent. I've seen this happen to me at multiple companies. It works. – anaximander Jan 27 '20 at 11:23
4

Mike Cohn has a great article on Story Points. Some of the highlights are

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

...

Because story points represent the effort to develop a story, a team’s estimate must include everything that can affect the effort. That could include:

  • The amount of work to do
  • The complexity of the work
  • Any risk or uncertainty in doing the work

...

A story point estimate must include everything involved in getting a product backlog item all the way to done. If a team’s definition of done includes creating automated tests to validate the story (and that would be a good idea), the effort to create those tests should be included in the story point estimate.

Story points can be a hard concept to grasp. But the effort to fully understand that points represent effort as impacted by the amount of work, the complexity of the work and any risk or uncertainty in the work will be worth it.

Tiago Martins Peres
  • 2,084
  • 2
  • 14
  • 32
  • 1
    Yes, but he gives no rules how to convert each personal forecast of the amount of work, of the complexity, of risks into a one number estimate. So, as I said everybody understands Stoty Points differently. What is the use of them then... – Chris Brettini Jan 26 '20 at 09:12
  • You define them as a team. I mean, you come to the final SP for a User Story as a team. So, you reach an agreement because if one selects a rather low SP or high SP, then a discussion starts to understand what lead to that decision. Every time I've used SP there was only once or twice the team didn't reach a full agreement after discussion. Does that make sense? – Tiago Martins Peres Jan 26 '20 at 09:26
  • Not really. Agreeing SP is about naming things - one can label a Story with "10 Story Points", the other may label it "5 Story Points". But these are just labels - two different person may give different labels to the same thing. And it's difficult to achive a shared understanding of what we call 1SP, 2SP etc – Chris Brettini Jan 26 '20 at 09:32
  • They are labels that, as Mike Cohn explains, translate into effort to develop a particular US. You have a goal and, accordingly to your experience, this is 4 SP. Your other team member realizes something you didn't that adds up to the uncertainty and decides 12 SP. Then, you'll discuss to defend why. You realize you weren't considering that part that is uncertain and realize that maybe 4 isn't very good. So you decide to give 8 or 12 or even more. – Tiago Martins Peres Jan 26 '20 at 09:39
  • The Scrum Master gives often a boundary. Isn't like "Hey everyone, select a number from 1-100". SM can say something like "2-4-8-16-32-64" – Tiago Martins Peres Jan 26 '20 at 09:42
  • Within that range, if you select 32 SP for a very very very easy US (meaning it's rather complex, or uncertain, or takes a lot of work), then I'm sure your other team members won't agree with giving 32 SP to that US. – Tiago Martins Peres Jan 26 '20 at 09:44
  • But without the common rules these numbers are chosen and agreed really unreliably. How can you discuss and agree something you don't have a definition for? – Chris Brettini Jan 26 '20 at 09:44
  • You sure can obtain some estimation using Plannning Poker, but the question is what is the precision of these estimates? If the precision is only 30% then these estimations are pretty much useless. And how do you know the precision? – Chris Brettini Jan 26 '20 at 09:47
  • This to me is a definition «Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.» – Tiago Martins Peres Jan 26 '20 at 09:48
  • But hours is also "a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work". Why not to use hours? – Chris Brettini Jan 26 '20 at 09:49
  • There's many factors influencing precision. Skills of your developers is one. – Tiago Martins Peres Jan 26 '20 at 09:49
  • Yes. So at the end of the day how do we know that SP are more usefull than hours? Hours at least have a property of being understood by all team members the same way. – Chris Brettini Jan 26 '20 at 09:50
  • 1
    You can use hours if you want. But the amount of time you take to achieve something doesn't express the effort. Same logic applies if you're paid by the amount of hours, then the way you do activities / tasks is different than when you're paid by activity / task. – Tiago Martins Peres Jan 26 '20 at 09:52
  • This is the real reason? To avoid pressure of time and let developers concentrate on quality instead of meeting the completion date? – Chris Brettini Jan 26 '20 at 09:56
  • Very simple and repetitive task - 3 hours. Hard task - 1 hour. – Tiago Martins Peres Jan 26 '20 at 10:05
  • The development team works within boundaries of the sprint. They want to deliver the US they promised in the beginning of the sprint. It's more activity / task oriented. – Tiago Martins Peres Jan 26 '20 at 10:08
  • Why not just make the hard task last 5h? – Tiago Martins Peres Jan 26 '20 at 10:08
  • If they really want to deliver what they promised they should strive to estimate precisely in hours to forecast what could be selected for the Sprint - it is not task oriented, it is hours oriented. I'm not sure what do you mean by hard last 5h - different tasks last different time – Chris Brettini Jan 26 '20 at 10:17
  • Taking longer doesn't mean it's harder. – Tiago Martins Peres Jan 26 '20 at 10:18
  • But what do we need to know when we are doign a project? We need to know the amount of time, right? Not the level of hardness. The customer isn't intrested whether it is hard or not - they want to know the amount of time. – Chris Brettini Jan 26 '20 at 10:20
  • SP are more useful in the long run. You'll know "my team is capable of handling X during a sprint". – Tiago Martins Peres Jan 26 '20 at 10:22
  • And you'll know what X means IRL because you gonna have metrics. – Tiago Martins Peres Jan 26 '20 at 10:23
  • But why do we need to know this X? How do we use this X? What metrics? – Chris Brettini Jan 26 '20 at 10:23
  • Various reasons. Dev team can understand its average performance how, when was the best moment and worst, how they can improve. Know if and why you need more people. – Tiago Martins Peres Jan 26 '20 at 10:29
  • We first need to prove that there is a strong correlation between SP and the performance. Maybe we just want to believe in SP. – Chris Brettini Jan 26 '20 at 10:34
  • Do you have one for hours too? – Tiago Martins Peres Jan 26 '20 at 10:35
  • When we are talking about hours it is easier to understand each other, the conversation becomes more concrete, we can detail the estimate further and get more reliable amount of time. The release date becomes more reliable. This is the applealing property of hous to me. – Chris Brettini Jan 26 '20 at 10:48
  • 2
    Dan Radigan - «Hours don't account for the non-project related work that inevitably creeps into our days (emails, etc). Hours have an emotional attachment. Each team will estimate work on a slightly different scale, which means their velocity (measured in points) will naturally be different. This, in turn, makes it impossible to play politics using velocity as a weapon. Story points reward team members for solving problems based on difficulty, not time spent (This keeps team members focused on shipping value, not spending time).» – Tiago Martins Peres Jan 26 '20 at 10:54
  • 3
    @ChrisBrettini Story points are more accurate because humans are notoriously bad at estimating time. It's hard to estimate a number of hours to allow for "there is still some uncertainty about how this will be implemented". It's easy to compare a task to something you did before and decide if it's bigger, smaller, or similar. Points deliberately aren't the same across teams, which means you can't say to Team A "here, Team B says this is four days of work, so it'll take you four days, right?" Team A has to estimate it for themselves, which mitigates the "mythical man-month" problem. – anaximander Jan 27 '20 at 11:16
  • 1
    Also, "The customer isn't intrested whether it is hard or not - they want to know the amount of time" this is true, but the customer should not see story points. Story points don't mean anything to anyone outside of the team who estimated the stories. The points can be used to decide how much work fits into a sprint, and at that point, whether it's hard or not is very important. Story points can be used to estimate how many sprints worth of work is in your backlog, which can be used to give your customer the estimated delivery date they want. (Note that this will shift as time goes on). – anaximander Jan 27 '20 at 11:20
  • 1
    @anaximander using story points to estimate how long the work in the backlog will take is problematic and I'd stay away from that. Story points have no bearing to time purposefully. They're simply used in the 'now' to compare how big something is to something else. Trying to extrapolate time and estimates from them is a recipe for disaster. – George Stocker Jan 27 '20 at 18:08
  • 1
    @GeorgeStocker I totally agree, and I've seen it cause all sorts of problems (one place I worked even "calculated" that a story point was worth 2.5 hours and based everything off that, which really didn't work). What I mean is that you can use story points and velocity to decide how much work will fit into your sprint (which is normal), and this can be extrapolated to estimate very loosely how many sprints of work is in the backlog, but when I say it will shift, I mean that really, this sort of estimation is only accurate to one, maybe two sprints in the future. – anaximander Jan 28 '20 at 09:11
1

Without external measuring devices, I can compare two cups of water and guess which one is fuller than the other.

I can't tell you how much exact liquid I can fit in the cup, nor can I tell you whether putting the liquid from one cup into the other will result in overflow without trying. If both are really full I may have some ability to do so; but it depends on the relative sizes of the cups and how much water appears to be in each.

My point is: while I can make inferences and deductions trying to compare the two cups to each other; I can't tell you much else, because it's unknowable without more precise measuring and a scientific process.

Software Development is anything but a scientific process -- it's about as far from science as you can get. I guess that's why we call it "Software Development" and not "Software Science"

Story points are used to measure work against work done in the same sprint; and their values are relative to the work being done. Much like the water in the cup, they have no measurement or relevance to work done in the past or work yet to be done -- that requires measurements that we don't have because we're not really able to measure the changes in environment that cause software to be built or not be built.

For instance, any of the following can affect velocity:

  • New Team member
  • Bug contains a dependency we didn't know about
  • Team member has an issue with another team member
  • a software development environment upgrade causes unforseen side-effects
  • NPM goes down
  • After starting development, a developer notices the problem is deeper than we knew
  • A developer gets confused by another developer's 'clever' code
  • Any one of the items listed here.

My point is, any estimation technique that attempts to do anything other than size the work immediately in front of you with work that is also immediately in front of you is subject to extreme disappointment.

There are two ways around this:

  1. Break down work so small it's easily estimable reliably.
  2. Work on one thing at a time, with the whole team working on it, to ensure there are no blind spots or tracks that can collide (Mob Programming).

Most teams I've seen that have run into problems with Story Points have tried to use them as some sort of estimation of how much work can be done in a sprint reliably in a dynamic environment; or comparing velocity over time, or thought of them as a reliable measurement of absolute estimation.

George Stocker
  • 929
  • 5
  • 8
  • 1
    The two-cups-of-water analogy explains quite neatly where the value of a point comes from. Given two different cups, you could eyeball that their sizes have a roughly 3:5 ratio (for example) but that doesn't mean that the smaller cup holds 3 litres, or three pints, or three of any particular unit, it's just about three-fifths of the larger one. It also explains the use of Fibonacci numbers - given a very large cup, you likely can't eyeball the difference between 25:3 and 26:3 very accurately, but you could probably decide whether it was closer to 21 or 34. – anaximander Jan 28 '20 at 09:15