I've used T-shirt sizes: S, M, L, XL, and that seems to be a good gauge. Anything beyond XL needs to be broken up into multiple stories. This maps to 1, 3, 5, 8

I've used T-shirt sizes: S, M, L, XL, and that seems to be a good gauge. Anything beyond XL needs to be broken up into multiple stories. This maps to 1, 3, 5, 8, etc or whatever your tool uses. Numbers are easier to sum than sizes, so that is what gets used in management software. Agile tries to balance feedback to management with the inherent uncertainty in software development. Most managers are happy to hear something like "This is two big things, and 5 little things." Any analysis beyond that is a exercise in futility. They understand a small thing may take a while for a junior engineer but be a footnote in the day of a senior engineer. So time doesn't really make sense. Lines of code and checkins are both arbitrary metrics that don't necessarily reflect the work put in. I have spent days or weeks on issues that resulted in single line changes, and cranked out hundreds of lines of code in an hour. What else can you measure? Turns out there aren't very many good metrics for software engineering or other knowledge work. All you are left is a "feeling" of "effort." This is really a judgement call that you can only make by combining personal and team experience. If you are jumping from contract to contract you likely don't have the time to calibrate to a specific team's feeling. Any metric is subject to being gamed, at which point its useless. By not saying "X of Y equates to Z story points" you avoiding creating gameable metric. If points are tied to a concrete value, then people will adjust for that value to try to get promotions/raises/notoriety instead of delivering a quality product. Knowing points are arbitrary makes them less appealing to game. I struggled with the same question early in career. As I've gone through more sprints I have taken the Whose Line is it Anyway's approach that Agile is "[a] show where everything's made up and the points don't matter". Its not completely made up, but your job is develop software, not assign points to stories, so focus on your job and assign points based on what feels right. If you find you are often wrong when assigning points, adjust accordingly. In the end, points are only really used for a "big picture" for management. They understand an individual story's points isn't exact. But if the team wildly swings on points sprint to sprint, then someone thing up. Either they are not consistently finishing work, not correctly evaluating work, or something else. So think of less an absolute measure, and more of a relative measurement of output sprint to sprint. That is why each team points their own work, and teams shouldn't be compared to each other based only on point value. This is all predicated on that management understands Agile/Scrum. If a manager is too focused on points, try to direct them back to concrete Todo/Done lists, as that is what really matters. Sometimes they will try to manage via points, and this will fail everyone in the long term.