How do story points relate to hours

Same as physical work, this quantity would be independent of the amount of effort or time. It would be the same for everyone, effort put in will change the time required, but the work done is the same - producing a piece of software which meets the functional and non-functional requirements specified upfront.

The unit of work in physics is Joule, let's call the unit of work in software as Scripton. Suppose the Oracle says that adding a video call is Scriptons of work.

We gave the same story to teams - A, of experts, and B, of novices. Assume team A took 5 days to finish it, whereas team B took 20 days. Team A is effectively 4 times as productive as B. Having this Oracle will make numerical analysis of productivity and predictability possible across teams and time. Despair not! Relative values are still useful as we saw in the previous section on productivity. Story Points is that relative value. Since, it is a relative value, there has to be a reference story.

Continuing with the scenario set in the previous paragraph, suppose both teams designate that story as their reference. These SP numbers are totally arbitrary for now, but what they are trying to measure essentially is the underlying work.

In fact Team A was 4 times as productive as B, as noted above. Now, another story comes - record video call. There is some discrepancy between these estimations but there is no Oracle to tell us exact values anyway. When we multiply these SP values with their respective velocities, we will get the due date with reasonably good accuracy.

So, we make do with a relative unit. How do we measure the relative unit? The basic process is very simple. A team is assembled for the first time, they pick a well-rounded story. After finishing the story, they give it some arbitrary number. They pick another story and compare the amount of effort to the first story and assign it a relative number. For example, they may agree on the current story being 3 times the effort of the first story.

They repeat this a couple times. Then at the end of the sprint, they calculate their velocity by dividing the total SP with sprint time. If the velocity is stable in the first few sprints then it means the estimations are good.

If everything else remains the same, real velocity would not change drastically in the span of a few sprints. The goal is to make objective estimations, which means attention must be paid to all parts of work and human biases should be eliminated as much as possible. Using Delphi methods, like Planning Poker, is advised to reduce biases like Halo effect and Bandwagon effect. Averaging and Fibonacci numbers are used to come to a consensus in case of divergence of estimates.

As we saw in the Work-Time-Power analogy, SP is an attempt at measuring the amount of work, but the estimate could be wrong due to a whole lot of reasons.

Some common ones are -. I could foresee 3 glitches in this game…. If OPA is not in place, collaborate with customer and team, assess the ROMs not from best available talent in the team perspective but from moderate talent. IMO, business values are typically assessed with be-spoken statisical tools like pay backs, NPVs, monte carlos so on… Hence key stakeholders are expected to have a near- to- realistic vision for business value.

Its pretty natural phenomina to win savings along side the project progression as the team gets accustomed to the project relatively mutiple times than what it is initially with first sprint. So its not a good idea to compare velocity at par with productivity.

Here the productivity is pretty pinnacle but the velocity might be low. IMO, velocity is as good as stretching from the very begining of the project disregarding progressive celebrating milestones. This is how I look at this scenario. Typically helps establish a start up estimate at higher level. We employ PERTs and wild guesses leveraging experts opinion for schedules.

Its used to calculate present value of investment leveraging its potential value after n years. For Velocity, I also contributed the same as other contributors did. The more we keep learning from sprint to sprint, the lesser time we take for completion. Hence I find it odd to caompare velocity with productivity. EOD, its one of the mesures to validate productivity and not by itself tantamount to productivity.

In my view, velocity can be a measure of productivity improvement for a team but only at the start maybe first sprint but in long run velocity cannot and should not be used as a metrics to measure performance rather it should be just used by the team and for the team to get some predictability to map their release plan or to give some high level cost estimates to management. In the long run, consistency in velocity is important than increase in velocity.

In case a team is showing continuous improvement in velocity over a long period it should be seen with a dash of doubt and warrant a check on whether the team is faking out velocity.

What was found, is a few common themes or messages appearing. In no particular order, here is the top advantages of using story points and top disadvantages of using story points:. It would make a few academics shudder at the thought of using blogs and search engine results as evidence, so I dug a little deeper and looked at some academic publications.

And a bunch of others. But I could not find any publications on comparing story points to hours from a reputable academic journal or the like. If you know of one, please email me.

Firstly, lets seperate out two concepts used in story points estimations that sometimes get tangled together:. It is possible to do relative estimations without using fibonacci-like sequences and vice versa. This is important to note for our analysis. Relative estimations are used to compare something with a reference.

It is believed by advocates of story points that using points, and not hours, can lead to better judgements and therefore better accuracy. Being a scientist, I have looked for evidence on this and I have not yet been able to find anything conclusive. Actually, the best and most independent evidence I could find says the opposite.

His first is to make comparisons to similar projects and use work hours. He found story points led to less accuracy.

Story points based approaches usually use a Fibonacci-like sequence such as 1, 2, 3, 5, 8, 13 … etc. It is perceived this can help with quicker estimations as there are discrete choices to be made. It is possible to use a Fibonacci-like sequence using hours such as 1h, 2h, 4h, 1day, 2day, 4days, 8days … etc. So, if this is a format you like, you can still use it without story points. A quick note, watch out for the central tendency of judgement where the result can get skewed towards optimistic.

Suppose that an octopus and I each estimate the effort to wash my car. The octopus has four times as many arms as I do. So, presumably, the octopus can wash my car four times faster than I can. But the octopus will also be four times faster than me at washing any car.

So, the octopus and I can agree that perhaps my two-seat car can be estimated at 5 story points and a second, larger car can be estimated as 10 story points. So, then, the octopus and I can agree on a number of story points, even though the octopus is presumably much faster than I am at washing cars.

You may need to read that paragraph again. It is confusing. It can get even more confusing if you introduce a giraffe that is awesome at large cars but not very good at bending down and working on small cars.

The argument starts to lose its weight and when teaching people I believe in the keep it simple philosophy. So, how do we take into account that some people work faster than others? The answer is to estimate based on what a qualified or reasonable person would be able to do. For our example, estimate on how long it would take a human to do the task, not an octopus. If you do end up with an octopus in the team, then great! That is your advantage and this should give you some extra time to do an awesome job.

I do understand that this argument is in the grey area. A counter argument I hear sometimes is that it is not as accurate as we are not taking into account different skill levels. Now suppose you had also tracked the amount of time spent on two-point user stories. Graphing that data as well, we would see something like this:.

If the one-point stories are centered around a mean of x , ideally the two-point stories will be centered around a mean of 2x. This will never be exactly the case, of course, but a team that does a good job of estimating will be sufficiently close for reliable plans to be made from their estimates. What these two figures show us is that is the relationship between points and hours is a distribution.

One point equals a distribution with a mean of x and some standard deviation. The same is true, of course, for two-point stories, and so on By the way, notice that I've drawn the distributions of one- and two-point stories as having overlapping tails.

It should be totally realistic that the biggest story that a team put "one story point" on might turn out to take more time than the smallest story they put a two on. After all, no team can estimate with perfect insight, especially at the story point level.