It makes me wonder why the Pentagon, with a US$1 trillion budget and being a critical piece of the US state apparatus, could not create a solution like that in recent years.
It's not only because of the schizophrenic process of estimating tasks' complexity (not time) to understand how many of them can be added to a two-week time window.
In teams that focus on points:
1. you spend time giving points to tasks in a meeting with the whole team
2. to calculate how many points can be added to a sprint based on the points given in the past, without any adjust for the cases where the points allocated to a task were wrong
3. to determine the group of tasks that will be assigned to each developer
4. to finally, discuss why the number of points assigned to a sprint was not fully delivered (it's rare to find sprints where the tasks are delivered earlier; Parkinson's law explains that)
It's unlikely that any stakeholder would prioritize a team's precise task estimation over the rapid delivery of features or projects.
In this sense, a kanban process will have the same outcome with much less energy spent, and small tasks will give you the same statistical value without spending hours estimating "complexity."
The Sisiphisean job of trying to assign the correct number of tasks to a sprint is only there to comfort team members who don't want to consider the actual value of the processes they use.
It makes me wonder why the Pentagon, with a US$1 trillion budget and being a critical piece of the US state apparatus, could not create a solution like that in recent years.