Scrum teams are self-managing, and point values are used for gauging your own team-workload. When you point a "0.5" and your team points a "5", stop and discus

Scrum teams are self-managing, and point values are used for gauging your own team-workload. When you point a "0.5" and your team points a "5", stop and discuss the discrepancy until an alignment can me found. Keep doing that, every task, until you a collective meaning of "a point" is found. Personally: * Less than 1 - These are a smell and should not exist. These misalign incentives and encourage "bike shedding". * 1 point tasks - no task that requires 2 people (dev and qa) is a 1-pointer, so this is something that needn't be QA'd. 1 point tasks should be rare items that can't be a subtask of a "real" task. * 3 point tasks - These can be done in a day (depending on the team's opinion, this might be multiple people and still be 3 points). Virtually every task should be a 3. * 5 point tasks - These are tasks that cannot be broken down to be done in a reasonable amount of time. These are generally things that have minor external dependencies. ("not hard but I'll have to get a server spun up by the unix admins.") * 8 point tasks - These are rough tasks that haven't been fully dissected by the team and are the scrum version of a "code smell". The team should break these down and dissect them. * 13 point tasks - "There be dragons here" tasks. Large unknowns and these tasks should not be added to a sprint until they're broken down further.