Some teams start using zero point stories to mean the Team “should not get credit for this work.” This is because they are doing something which the Product Owner does not see as valuable. There is a problem here in the Story Points represent how big a job is and, when summed to make a velocity, how much work capacity the team can take on. Zero points means “there is no work to do.”
What is the effect of zero point estimates? If you end up doing roughly the same amount of work sprint over sprint for these zero point stories, then the velocity of the team should not be impacted as it will have no real positive / negative impact. OK good. But what I hear from some teams is that there is large variation from sprint to sprint for these zero point items (eg one team reported that they have to do the build process only once every three sprints, and that is a lot of work but was not reflected in the points the teams completed) which means they do not end up with a stable velocity. Worse it makes it hard for the team to use the points as a basis for their capacity. I am also concerned that if we put things like “new learning” as zero point stories, we potentially drive these activities underground (team decides to do them anyway) and that is not a good thing. To me we need to have a cost / benefit discussion on things like learning with the Product Owner as the key player in that discussion so that we don’t drive this work underground.
It seems like these are an encoding. If the encoding has a detrimental impact on the main use of points (estimates, planning, transparency) then I would consider some other approach. If it does not, and the product owner in particular is OK with what is happening (that’s who / why we provide this information to / for) then there is no reason to change.