In Agile, there is a concept of story points. Story points are used when an epic (or large story) is too complex to estimate in hours. Instead, story points are meant to measure relative complexity. For those in the know, it uses a quasi-Fibonacci sequence to compare expected effort of two or more challenges.
It’s important to note a few aspects of story points. First, they only have context within a team with a fixed composition. Story points for a different team or a team with different members are not comparable. It’s apples and oranges. Second, story points are neither measures of time, or convertible to time. If you have a project management layer that ‘needs’ to track progress, by the time a story is accepted into a sprint, a story or task should be estimated in hours. Technically, Agile has no commitment to output, but project managers and managers more generally tend to expect this, and so hours need to be estimated for resource planning, velocity, efficiency measures, burndowns, and so on. Story points don’t burn down. And they aren’t a unit of measure of time in the first place, so what are you burning down? You had a 200-point project and have worked on it all day. How many points did you burn? This is not knowable.
If people are mentally equating story points to hours, this is an added (and unnecessary) complication, and the time element should be captured directly.
Practically speaking, attempting to measure velocity with points is almost analogous to measuring a 100-meter dash with a calendar instead of a stopwatch—but not even that, because at least a calendar is a valid time measurement. Because the unit of measure is relatively so much larger, the burndown charts show little movement until the last few days. With hours, a developer can record actual hours used against allocated hours to determine progress and completion status. Recording how many story points have elapsed in a period is not so straightforward.
As another example, capturing story points as a proxy for time instead of relative complexity would be like entering English into Google Translate to document requirements (or a user story or acceptance criteria) into Farsi—where English represents time and Farsi represents points. When it comes time to determine progress, you’d need to put the Farsi back into Translate to get it back into English—story points into hours. Of course, since story points were never hours in the first place, it would probably be more like starting with English but running it through Chinese, Russian, Tagalog, and Kalahari before saving it as Farsi, and then translating it back to English via the reverse route. I hope this sounds ridiculous because this is how ridiculous it is to expect to be able to get meaningful progress and status information trying to track a project based on story points. Don’t do it. No way. No how.
Don’t say I didn’t warn you. You’ve been warned.