8

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.

  • I think people are voting for a popular interpretation of scrum, not the formal definition asked for, which is why the top answer here was not accepted – Nathaniel Rink Jan 7 at 16:05
13

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.

  • I don't think it can be called disingenuous. The PO is getting 5x more tables in the same amount of time. That's a legitimate increase in velocity... But thank you for the link. I'm going to read it now. The problem with effort is that I don't see how a team's velocity can increase exponentially over time if every time they figure out how to do something faster you redefine the size of the same story. It seems like it would disincentivize innovation. – Nathaniel Rink Dec 31 '18 at 19:30
  • 4
    It's only a velocity increase if story points are a measure of output, and I have always seen story points defined as a measure of effort. In my experience, it is assumed that a team will become more proficient over time. If it takes me one point to add a record to a database, and I then create a script to add one billion records, does my velocity increase by one billion points? That would be absurd. Velocity may increase over time, just not exponentially. – Dan Wilson Dec 31 '18 at 19:35
  • 2
    @NathanielRink. Story points are not a measure of production. They are an estimate of effort. As in dans quote. – Ewan Dec 31 '18 at 23:09
  • 6
    @NathanielRink, The problems start when you have multiple different stories of 8 points, where some of them take 1 day to complete and others take 1 week. Then your story points have become useless to estimate how much work the team can pick up in a sprint and you need to make a second estimation to know what you can plan for the next sprint. – Bart van Ingen Schenau Jan 1 at 9:32
  • 1
    Regarding your first comment, if developers are genuinely disincentivesed from innovating by reducing the story points...they don't sound like very good developers to me. All good developers I know want to innovate and want to make programs and processes more efficient, regardless of story points – matt freake Jan 4 at 12:53
9

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.

5

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.

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).

-2

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.



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.

  • I appreciate all the discussion here, but the question was to document the formal / official answer; not discuss subjective opinions. I think the answer provided by the Scrum Co-Creator and his son / CEO of Scrum Inc. is the one that answers this question with the definitive official answer. – Nathaniel Rink Jan 2 at 22:55
  • The only problem I can't reconcile with this answer is comparing stories of similar sizes. If you find a way to produce 4x as many of Widget A, but not Widget B, and you had originally estimated both widgets at 5 points each, does that mean Widget B is now 20 points? – Greg Burghardt Jan 3 at 2:04
  • Yeah, it's a little counter intuitive; but I think mainly because no matter how hard the brain embraces story points as not time, the heart sort of still wants to think that way. I think the Scrum analogy would be if you drive 60 miles on a highway, it takes an hour and your velocity is 60 mph. If you drive 60 miles on back roads it could take 3 hours and your velocity is 20mph. But the size of the story (60 miles) hasn't changed. It's just that one 60 mile section has a higher velocity than the other and if you drove all 120 miles (two different stories) your team velocity would be 30mph – Nathaniel Rink Jan 3 at 16:47
  • Then the idea is, you're not actually only working on 1 story per sprint and using that as velocity. A team should generally be working on 10-15 stories per sprint and averaging the velocities of three sprints; which normalizes your velocity. – Nathaniel Rink Jan 3 at 16:48
  • Hm. I understand your road analogy. I don't think this answer deserved a down-vote, but I think the fundamental problem here is that people would assume that a 60 mile stretch of freeway is the same number of story points as a 60 mile stretch of gravel road (larger difficulty). This hints at the root of this question. How can you possibly commit to a four 8-point data table stories and then also justify why you can only commit to a single 8-point Widget X story. If this answer is actually true, then story points seem fundamentally broken. – Greg Burghardt Jan 3 at 17:53

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.