Do Story Point sizes for repetitive tasks change after you automate the task?

Question

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.

Answer 1

Your back-end table stories no longer require eight points of effort.

“A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements“

scrum.org

If you continue to estimate back-end table stories at eight points then you will skew your velocity as a measurement of effort per sprint.

It would also be disingenuous to continue assigning eight points to work that you know only requires one point of effort.

Answer 2

Increasing velocity is not a goal. The goal is reliable planning.

Story points are a tool in a feedback loop that will tell you, over time, what your typical velocity is. This will then tell you how much points you can realistically adopt in a sprint. Velocity may drift a bit over time but if it changes too quickly it is useless. A sudden increase in velocity would only tell you that you still don't know what you are doing. So you want to keep your velocity constant, that tells you your estimates have been good and will likely be good for the next sprint.

You know your output is not constant, you are aware of the fact that you can create tables much faster now. So it would totally defeat the purpose of your planning cycle if you insist on linking story points to deliverables.

Again, velocity is not related to productiveness and an increased velocity is no reason to celebrate. A story point is ultimately a chunk of your sprint. To make it more real, some teams define a well known task that everybody understands and call that the standard story point task so any piece of work can be related to the standard task in terms of complexity and time consumption. Needless to say if the standard task becomes easier, everything will shift and everyone will have to adapt to the new meaning of one story point, which sucks. The right and convenient way to go would be to define a new standard task that is equally challenging to the team.

Answer 3

Story points reflect how much effort it will take to implement the story. They are a prediction of effort. If the amount of effort goes down, so should the number of points.

Remember, the points are a tool to help you estimate. Nothing more, nothing less. They aren't a reward or a metric that measures output. They are simply a way to estimate how much work will be involved in accomplishing the goal of the story.

You say this task originally took 8 points, which equalled about one week. Now let's say your sprints are one week long, so in planning you're going to pull down 8 points worth of stories. If you keep this story at 8 points then you can only plan to finish this one story in the sprint. If the actual time is just an hour rather than 40 hours, what are you going to do with the other 39 hours? You've just created a very poor plan for your sprint because of inaccurate story points.

if the story is more accurately represented as one point, that means you can still pull in 7 more points in the current one week sprint. That seems to more closely reflect your reality, so changing the size of the story makes sense because it helps you plan.

You mention in your question a desire to improve velocity, but that's not really what you should be doing. At least, not in the literal sense. Your productivity will naturally increase, but for the sake of planning your velocity value should remain fairly constant.

Answer 4

Think of the effects. Say you have a team of five, a velocity of 100 points in a sprint, and you reasonably expect everyone to handle 20 points. Now you have this task that has become trivial, but still gets eight points. One team member grabs five of these tasks, does them in two days, puts his feet on the desk for the remaining eight days, beats everyone by handling 40 points worth of tasks, and gets a bonus. Everyone else gets chewed out by the boss.

If you are happy with that, then don't change the points for this task. I wouldn't like that situation.

Every task with the same number of points should be expected to take a developer the same amount of time.

And I totally, totally disagree with Nathaniel's answer here. Keeping the points would make velocity totally unpredictable, because some tasks will be done faster, but others aren't, so a sprint with accelerated tasks will give you a huge velocity, and the next sprint our down again.

It's also not how you would estimate. If I know that I have ten rather similar tasks, I don't give them the same points in the first place. I give a lot of points to the first one, meant for "doing the tasks and building the tools to do similar tasks very quickly", then much fewer points to the repeated tasks.

It's a different situation when a junior developer starts, or a developer joins from a different team, and increases their velocity other time because they learn (how to do their job in the first place, or all the bits they need to know about the particular project).

Answer 5

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:

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.

Answer 6

I find the question, answers & comments all highly interesting. Here is something complementary in my eyes:

Scrum.org is in favour of Story Points just tracking Effort, for more reliable planning/forecasting (Ref in Dan Wilson's answer). I can understand this.

Scrum.inc says that "Story Points are a measure of Output/Production, correlated to but not necessarily the same as Effort" [2] & they should not change for a repetitive Item, for the sake of measuring how process improvement affects capacity for work ([3], Refs also in Nathaniel's answer). I can also understand this.

So how do we make ends meet?

Effort

Effort for a repetitive task will diminish over time (if you're doing Scrum right) & in Scrum you always want to keep as close as possible to reality (not fantasy). You could therefore argue that one should expect (and want) Effort-based scoring to change, otherwise it will look more & more like lying to oneself:

• Sorry John, forgot to tell you -- we always score this particular Item as a (5), even though now it's completely automated.
• Huh? Why?
• Because we've always done it that way.
• ...
• It dates from 6 years ago when our financial system was based on Excel & we had one intern do it manually.

If you keep the same score forever & don't attempt to rebase it at least once in a while, you'll be repeatedly committing to the written record all the issues & idiosyncrasies of the past.

I can understand why Scrum.inc might favour keeping scores stable (it will more readily show that Scrum works), but this does not feel like a complete solution.

Value

Value is the one thing Product Owners need to maximise, i.e. given your team's current ability to deliver, how do you sandwich stories & order your Product Backlog to maximise the Value delivered each Sprint?

Value (in a PO's definition) therefore, is captured only implicitly by the position of a User Story in the Product Backlog, but following Sprint Planning it gets dissipated, since all that remains are Developers' [typically Effort-based] estimates.

So,

• if we want more reliable Sprint Planning, we need to inspect & adapt Effort-based points
• if we want to plot Process Improvement, we need to keep points steady
• if we want points to track Output (not exactly Effort) & want Output to mean Valuable/Meaningful Output, we need to find the PO a seat at the poker table, in a way

A Suggestion

1. Capture Value explicitly in each Item, i.e. call out the ‘V’ in INVEST in a similar fashion to Effort-based scoring (Fibonacci numbers or something simpler like 100/200/300):

   • A most valuable Item to do this Sprint would get a V=300
   • Tech debt stuff might get V=100
   • An out-of-scope meeting one has been dragged into & cannot escape would get a V=0.

2. Let Developers track present, real-world effort as comes most naturally.

3. Compute each Item's ROI (its business Value divided by the team’s Effort estimate) to help everyone see where most productivity comes from.

Velocity then becomes a cumulated measure of delivered Value, with the important distinction that the learning curve surmounted by the team over time to make effortful work easier (like automating a task) is only contributing rather than detracting from it.