Story points normalization - same team, successive projects

What do you mean with projects? Is it the same product wich they continue to develop? In that case I would try to keep the same baseline, so forecasts are easier to make.
What can change (even if the team structure stays the same) is the velocity, which depends on many factors.

It doesn't really matter. In Scrum productivity is measured in terms of actual delivery, not story points.

From process perspective it makes sense not to change means of communication if they worked, so if the team would like to leave them unchanged, that's fine.

What reasons to change the story points scale do you consider?

> I would like to know if successive projects
> worked on by the same team should use the
> same baseline for estimating in story points.
>
> In simple terms, should 5 story points
> estimated in Project A a few months ago be
> regarded as having the same complexity as 5
> story points in Project B now, assuming the
> team structure stays the same?

No, because the team's estimation baseline is not actually a number, but rather their common perception of the teamwork that is likely to be involved. That baseline should be continually improving as a result of their collective experiences.

No, because the team's estimation baseline is not actually a number, but rather their common perception of the teamwork that is likely to be involved. That baseline should be continually improving as a result of their collective experiences.

AFAIU your answer, the same concept is applicable also for one project. Correct? e.g. if team estimated story for 5 SP and few months later similar story was estimated for 5 SP means there is no improvement.

> if team estimated story for 5 SP and few
> months later similar story was estimated for 5
> SP means there is no improvement.

Evidence for improvement in estimation is not a matter of the points given for any particular story. It's a matter of the team being able to give a better forecast of the amount of work they can take on in a Sprint. An improvement *might* have the effect that you describe on a certain kind of user story. Then again, it might result in a better estimation if the team's capacity. The only real evidence for an improvement in estimation is the team's ability to forecast the deliveries they actually make.

You need to be careful not to bring command and control behaviors to Scrum. The Scrum team should aspire at self-management, and their measure of success and productivity should be the delivery of value to the customer.
Trying to bring KPIs to the agile software development process is fraught with dangers to the quality of the code, and to productivity.
The best approach to measure the performance of a team IMO continues to be velocity. The mean velocity over time with x standard deviations may be a good measure for process control.
You can also use cycle times, and touch times from Lean to understand how much waste (impediments) are in the way of producing valuable software from the point of view of the customer.

if team estimated story for 5 SP and few months later similar story was estimated for 5 SP means there is no improvement

That is an incorrect conclusion Bartek. Story points are based on the size of the effort, not on the time it would take to complete it. A team's velocity may increase due to their ability to complete more 5-point stories within a sprint. However. the 'size" of the story remains the same.

Think of the task of moving a boulder from location A to location B. A few months ago, the team may have estimated it at 8, and moved it by hand. Now, the team may have gained the technical/business proficiency equivalent to moving that boulder by crane. The team can get the job done quicker, but it is still an 8-point boulder.

If you are suggesting that a story should have a lower estimate compared to a similar one from a few months ago, wouldn't that result in an overall lower team velocity? How is a lower team velocity considered an improvement? And if your suggestion is that it should be higher than the similar story from a few months ago, how is that an improvement?

If the team is stable, then their estimates should remain consistent relevant to the team's understanding of the work. Also, do not read an increase in team velocity as an indicator of improvement, or a stable velocity as an indicator of a lack of improvement. Many factors can come into play affecting a team's velocity (team stability, knowledge transfer, cross-training, grooming quality, etc).

> That is an incorrect conclusion Bartek.

My conclusion is incorrect, or Ian's reply, which I concluded from, is incorrect?

> A team's velocity may increase due to their ability to complete more 5-point stories within a sprint. However. the 'size" of the story remains the same.

Yes, I understand that. How would you reply to the original question, then?

should 5 story points estimated in Project A a few months ago be regarded as having the same complexity as 5 story points in Project B now, assuming the team structure stays the same?

>If you are suggesting that a story should have a lower estimate compared to a similar one from a few months ago

No, I didn't mean to suggest that.

Thank you all for the interest expressed in this topic!

Regarding the latest twist of the discussion, which of the following applies:

- a user story that is very similar across products is estimated with the same story points count. The result is that the team velocity increases as they become more proficient in accomplishing their work?

OR

- a user story that is very similar across products is estimated with less story points as the knowledge and productivity around the topic increases. The result is that the team velocity stays the same as they become more proficient in completing their work?

Either of those scenarios is possible. Improved estimation by a team simply means that they can make a better forecast of the amount of work they can take on in a Sprint.

Note however that if one story "is estimated with less story points as the knowledge and productivity around the topic increases", then all stories in the Product Backlog ought to be re-estimated accordingly. The Product Owner may use such data when prioritizing items, and he or she must be in a position to perform meaningful comparisons.

The story size is relevant only to the team estimating it. Granted, the proficiency of the team may increase over time, but that does not change the size of the story.

One exercise I have done with past teams is to have them revisit past sprints and analyze the size of the completed stories. Were all 5-sized stories similar in scope? Were all '8' story-point stories of a similar size? This helps the team develop a better understanding and clarity around their communal estimation view of story size.

The team should also have the flexibility to adjust PB estimations as needed based on knowledge gained over time. Perhaps the team identifies a simpler approach/solution for a story, and it no longer represents the size that the team originally identified.