Zero estimates

Zero what? Zero points, or hours, or something else? Also, are they voting "zero" for the story or one of its tasks? You've used both words here.

Assuming it is story points, remember that the implemented story has to be peer reviewed and tested. As a minimum a unit test should be put in place, and the work will need to be peer reviewed for conformance with the Definition of Done, and then demonstrated to the Product Owner who presumably sees value in the story the first place. Whether you baseline all of that to a half or 1 is up to you.

Hi Filip,

Its nice to see that at least the work is visible. Some teams may not even capture this even though it is considered minimal.

Are you a member of the Dev Team or the Scrum Master?

As a Dev Team Member, I think the dialogue is helpful. i.e. "0 because..." or "1 because...."

As a Scrum Master, there is just facilitation needed to see what makes sense for the Team.

I would --
A) Look back to bring some awareness of how much effort it took for a bunch of such Stories / Tasks.
B) See whether the Team is completing the work forcasted Sprint after Sprint.
C) Bring awareness to the Definition of Done, agreeing with @Ian to ensure it is robust and includes these items.
D) [Sneaky] -- Remove the "0" card from my Dev Team members one sprint planning to see what happens.
;-)

Looks like you are alluding to the "Playing Poker" approach. When it comes to sizing I would always recommend using the relative sizing approach so even if you play poker bear that in mind.

So if your mates want to vote a "0" and assuming they are referring to points or days or hours it implies that they feel its of negligible effort.

Never fall into the trap of asking your team how many hours or days it going to take. That goes against the Spirit of Scrum. One of the things I tell my team when a similar situation comes up is to keep an open mind and expect change. There have been several cases when a team member has marked a task as trivial only to be surprised when things start unfolding.

So at the end of the day if the team is pretty sure that its a task with negligible effort then you should probably estimate it at the lowest end of the relative scale you are using.

Remember no task is a zero effort task if you are a good engineering team. There's always integration testing or documentation or something else to always make it perfect and engineering be short of ways to perfect things.

Thanks for your opinions, and sorry for a really late reply.
What i really did was talking with the team, asked them what they really have in mind when saying the task is a 0 card.

After a talking, we all agreed that a 0 task is
- something that's outsourced from us
- somethign that all team is agreed that is 0 complicated to do.

The main thing important here is I think that all the team has to agree on that, so they have to talk about reality.

Filip

Just some addition.
For my team the 0 means that the story is already implemented. Nobody has raised that card until now, because the PO knows his product and what is already implemented.
If your team picks that card for a very low effort, maybe your reference stories need some adjustment. As a rule of thumb, take the smallest story you have and assign a 3 to it. If you assign the 1/2, it can easily happen that a new story gets the 0 because there is no room left for smaller stories.
But the most important thing is: Do not discuss about the size longer than it takes to implement the story ;)

Do not discuss about the size longer than it takes to implement the story ;)

So true!