In Scrum, should a team remove points from (defect) stories that don't result in a code change?

Question

My work uses a Scrum-like process to manage projects. I say Scrum-like, because we call it Scrum, but our project managers exclude aspects of Scrum that are inconvenient (most notably customer interaction).

One of the stories in our current sprint was to correct a defect. After spending almost an entire day working on the issue, I determined the issue was the result of a permissions issue, so I didn't end up modifying any code.

Our Scrum master / project manager decided that no code change equals zero points. I know that Scrum points are supposed to measure size / complexity and not time, but our Scrum master invests a lot of time in preparing graphs and statistical information from past sprints (average velocity, average points completed, etc.)

I've always been of the opinion that for statistics to be meaningful in any way, the data must be as accurate as possible. All of our data is fuzzy to begin with, because, from time to time, we're encouraged by the Scrum master to "adjust" our size / complexity estimates, both increasing and decreasing them.

I'd like to hear some other developers / Scrum team members thoughts on the merits of statistics based on past sprints, and also whether they think it's appropriate to "adjust" size / complexity estimates in the middle of a sprint, or the remove all points from a story all together for situations similar to what I've just described.

Answer 1

To my mind this is a dangerous practice that to my mind jeopardizes the team's efforts as someone else can trivialize what was done. Granted no code changes were done, but the time spent should be allocated to something and this may become a black hole of time over and over again. The other side of this is that the team should decide how many points were spent on that, is a day's work roughly X points in your system? Where I work our estimates bounced between points and hours as the latter is what the project manager had to report up the food chain. Adjusting the points mid-sprint may be logical if the work has changed dramatically. For example, someone may think something will take a week but a day in may get it all done because it really wasn't that tough after all. Or the flip of that could happen. Either way, there should be updated tracking to note the changes in complexity of the task. This is something for either the doer of the task or the team to revise, not the PM as that undermines what the team does to my mind.

With practice and patience the estimates become better and more useful. The velocity can be really useful for knowing how much can get done in a sprint once it becomes a reliable figure. There are some risks in getting to that point of course and it seems like you have hit a mine or two that may prevent that from happening unfortunately.

Thus, for me the question here is who is running things really. Is it the SM/PM or is the team the one really calling the shots? The team should decide whether or not the points should stay. IMO, the points should stay because effort was expanded on the story. Whether or not some meaningful code fragment came from it is irrelevant to my mind.

Answer 2

In any point system, you are setting incentives, and creating outcomes based on those incentives. If you are not awarded points for fixing problems, what is the incentive (other than earning a paycheck) for making things better?

It seems pretty clear, based on your observation that customer interaction and feedback is avoided, and points are not awarded for lessons learned, that your company has defined quite clearly what they consider important and unimportant.

I think that speaks volumes.

Answer 3

Bugs should not be counted towards your velocity. Bugs actually have negative business value as they are work that was not properly completed in a previous sprint. What they do is LOWER your sprint velocity. If you feel that your velocity is not high enough because you are doing to many bug/support issues then you have an impediment for your retrospective. Maybe your engineering practices need some work. Maybe you need better test cases. Maybe more frequent and more thorough discussions with your customers.

In your particular case I would indeed say you had an incomplete/buggy feature because you took an entire day to figure out that there was a permissions issue. Sounds to me like some technical debt. Maybe better logging is needed. Maybe different code to not allow you to get in the situation. Maybe you have a story missing that you need in order to prevent this issue. If you find yourself with this problem often then maybe increasing the business priority of that story is in the PO's interest to help the team be more effective.

Oh, and the direct answer is that you shouldn't have removed points because you shouldn't have included them to begin with.

Edit: Based on some comments I'll explain a little more with an example.

Sprint1: Team claims 40 points of stories. But their dev process is weak and they don't get all of them tested. 4 stories (20 points) have critical bugs.

Sprint2: With the PO in agreement, the Team leaves 50% of the sprint to fix the undone, buggy stories from Sprint1. They also commit to 20 points of new work. They finish this work successfully.

So the sum of the 2 sprints is 60 points / 2 sprints and the average velocity is now 30 points. Thus using yesterday's weather the team will try for 30 in Sprint3.

Had the team included the bugs as additional velocity by estimating and adding in some points for them the team would continue to over-commit thinking that the average velocity was 40 when it is not; it is only 30.

Answer 4

One of the key issues I would have is that it sounds like the Scrum Master is more busy with statistics and data than with supporting the team.

In general, points shouldn't be re-estimated and changed when a sprint has been committed. Once a sprint is done, the velocity is just a number which can be used as a guideline, but shouldn't be overanalyzed.

We once had a sprint where it turned out that one of the stories was a lot more work than originally estimated in the estimation meeting. We didn't re-estimate it in hindsight, it was just bad luck.

Basically, story points are estimated at a moment where there is not enough information to account for everything that could happen. They are used by the team to have a basic guideline as to how much they can do in a sprint and they can be used loosely to compare sprints. They should not be used to actually grade the performance of a team. They're there to help the team be able to commit to stories and have a general idea about how much they can take on. So there shouldn't be any need to re-estimate any stories in retrospect. As long as the general velocity stays within a credible range or any peaks (low or high) can be explained, the velocity shouldn't be questioned or over-analyzed. It's a tool to get things done but shouldn't have any other meaning.