Should the complexity estimate of a task change in scrum?

Question

I'll just start with an example. We have a repeating task "Release library" which in the beggining we agreed on an estimate of 2 points: it seemed to be twice as hard as our 1 point baseline. As we have this task more and more often in our sprints, it got easier for us to do it, all the steps are known so now we tend to estimate the exact same task as a 1 point task.

Is this ok from scrum perspective? From my understanding, complexity-wise the task says the same thing and it should remain 2 points forever, just that now it's more simple for everybody, similiar to a 1 point task (which makes sense).

What should be done in similar cases? I see only 2 solutions which both feel wrong:

1. Estimate points remain the same, even though the task seems less complex than it used to be.

   2. Decrease estimate points, but then you might see a decrease in team velocity. (of course if this happens more often).

Please consider the example just an example, imagine something similar to any other stories.

Answer 1

Agile and Scrum make a big deal about constant vigilance to always improve as a team. Why should your estimates not follow suit in this manner? I would suggest to redefine the estimate of those stories that the team believes is a more accurate reflection of the complexity/work that it now takes, versus what it once was.

I found that keeping a set of reference stories that the team fully understands is best in helping to estimate future stories. Constantly refining what those reference stories were every couple of sprints was able to better the teams ability to estimate. This helped with future planning and ensuring that the new work's estimate was not inflated. Complexity of tasks shifts due to the team getting more used to one another, having gained better intimate knowledge of the code and becoming more experienced overall. It seems that you are seeing that your team is getting quicker at completing what once used to be a harder task.

The velocity in your Sprints will average out over time. Velocity is not an end all measure to an amount of work, but a tool that helps better estimate a work load the team can confidently complete in the Sprint timebox.

Answer 2

The idea of velocity is to allow a team to roughly predict what the capacity is for the next sprint. It has no other purpose than that.

So the answer to your question is to do whatever best helps you predict your team's sprint capacity.

It doesn't matter if the rolling average of velocity goes up or if it goes down. It is not a measure of performance or of team capacity. It is a simply an aid to planning that lets you put a reasonable amount of work in to sprints.

In the example you have given, I would suggest that if you leave the size at 2 points then you may end up under-estimating how much work to put in a sprint if it contains this type of story. It would be better to make the adjustment to 1 point so that your velocity correctly reflects what the team is likely to achieve in a sprint.

Answer 3

Maybe, a good aproach to conduce this situation is to always review the requirements and the efforts of the tasks before sprint starts.

Complexity is not always the same and it can affected at any moment depending of many factors (there is a very big study about this: http://en.wikipedia.org/wiki/Complexity). One factor is the one that you said "As we have this task more and more often in our sprints, it got easier..." (experience).

A tool that I use on our team to stabilish a point of complexity is the planning poker. It helps a lot, and believe, sometimes we play it twice (in different times) and we get different points of view.

Answer 4

If you decrease the estimate to 1 point, why does your velocity go down? Aren't you bringing in another 1 point of something else to match your predicted velocity?

If you keep it the same at 2 points, but find the team is finishing earlier, then aren't you finding that you can poach another 1 point of task work and that your velocity is increasing?

There is no right/wrong way to modify the estimate, your velocity will naturally adjust based on which option you choose to show that over time the task is simpler or that the team can handle more complexity. Just make sure you keep your estimation practice consistent.

Choose the option that the team can relate to the best AND ensures that the team's velocity and estimation practices remain in control of the team.