Agile – Do Story Point Sizes Change After Automating Tasks?

agileestimationscrum

Here's the Scrum situation:

  1. A certain task (implement a back end populated data table) is a frequent story
  2. The tables frequently have similar but custom functionality
  3. Each table takes about a week to implement (8 story points)
  4. Eventually the team invests 4 weeks to create a reusable component
  5. Now creating a new table is nearly instantaneous

My question:
Is a new table story still an 8 because output /complexity has not changed? Or is it a 1 because effort is minimal?

My Research: When I took scrum training with Jeff Sutherland I left with the understanding that the story is still an 8 because story points measure output. The PM is still getting the same tables, they're just being delivered 5x faster. It's a genuine velocity improvement (doing the same work but faster)

But I'd like to verify that my understanding is right. Any help out there? We are looking for the formal scrum definition, btw. I've researched scrum inc's site and gone through "The Art of Doing Twice the Work in Half the Time" and can't find documentation that my understanding is right or wrong.

Thank you!

Update
I was really looking for links to documentation by formal scrum authorities. I think this question is misleading now because a lot of the answers below are just peoples' opinions.

Best Answer

UPDATE 1/22: SCRUM INC RESPONSE

"It stays the same to represent equal value delivery. The velocity of the team is a key measure. Your process improvement should result in increased Velocity: https://www.scruminc.com/velocity/" --- Scrum Inc. Response via Twitter

MY SHORT ANSWER:

Dr. Jeff Sutherland, the creator of Scrum answers this question directly in his Points vs. Hours Webinar on slide 6

What are Points? Points are a measure of team OUTPUT. Correlated to but not necessarily the same as effort.

JJ Sutherland, CEO of Scrum Inc. answers it even more directly in his lesson on Getting Velocity Right

Just because the team has gotten better at implementing any given story, the point value you should remain the same.

MY LONG ANSWER:

Additional Sources. Since this question is controversial, here is research that answers some of the concerns voiced in other answers:

Yes. Scrum's goal is to increase velocity

Source 1

Although velocity tends to oscillate over time, as a rule it should trend upwards about 10% per Sprint. -- JJ Sutherland

Source 2

Slide 5 of Scrum Inc's Lesson on Velocity shows a velocity chart with a 12x improvement over time AND titles the chart "Output Improvement" with "Points" as the y axis:

Velocity Chart: 12x Output

Source 3

Go to ScrumLab.scruminc.com and look at the Metrics webinars. It shows how we measure company performance using improvement in velocity, the happiness metric, and the revenue per point. I hear so many slow teams complaining that going faster will just generate more crap. This is because Product Owners are not held accountable for doubling revenue per point. If you double velocity and double revenue per point the company will generate four times more money. This will make everyone happy. That is why you need the three metrics. -- Jeff Sutherland

Yes. Story Points Measure Output / Production

Source 1

The management metric for project delivery needs to be a unit of production Jeff Sutherland in his definitive article Why Story Points Are Better Than Hours

Source 2

If the Team starts to estimate stories at lower values because they have incurred substantially more experience and the stories seem easier, Velocity will never seem to improve. This is one big reason why estimating in hours doesn’t work. -- Scrum Inc CEO, JJ Sutherland

NO. Increasing Velocity Does Not Ruin Predictability

First of all, as a PO or executive predictability is very important, but productivity is even more important. Most POs if given the choice between maintaining production levels or significantly improving productivity at the expense of some small predictability would choose the increased productivity. That being said, the tradeoff is a false choice if a team employs the recommended Yesterday's Weather scrum pattern for sprint planning.

Using common sense... if a team produces 10 widgets a week, then finds a way to produce 40 widgets a week; their velocity has improved 4x. The PO is getting 4 times as many widgets in the same amount of time. Calling that flat velocity is contrary to the definition of the word.

YES. Gaming the System is Possible If The Whole Team Cheats

Finally - it's possible to game the system, but it's possible to game any system. Scrum minimizes the individual devs cherry picking stories by pulling from an ordered backlog and by measuring velocity on a team basis, not on an individual dev basis. If you measure dev by dev velocity you're not doing scrum. And it mitigates gaming the system through estimates by grooming stories as a group. To sandbag your estimates you have to do it in front of the group and the group has to collude with you. But if you want to game the system it doesn't really matter what process you use. Scrum does depend on a team of 4-6 motivated, capable employees interested in accomplishing goals together; but if you have employees who are cheating on work to game the system then your process isn't the problem.

Related Topic