[jayd16]

Does anyone actually run things like that? Where the goal of work is to earn arbitrary points?

Sure there are story 'points' for describing complexity in an int and daily check-ins but I thought counting tickets was up there with lines of code produced?

[Guthur]

It might be up there but it's all that an overly analytical and literal population can get their heads around. They literally can't think of any other way of making decisions. If they don't stick numbers on things they become essentially blind to it.

[Spivak]

Are there other ways? Like sure there's other systems that assign numbers differently and have different ceremonies but is there any way that works that doesn't involve assigning numbers to stuff?

The basic premise of people being simultaneously really good at estimating work and at the same time absolutely garbage at it when you make them use real dates naturally evolves a number system. Make up an arbitrary unit, have people estimate tasks in that arbitrary unit, and behind the scenes without telling them determine the conversion factor for that person so you can plan accordingly. Everything else is just flavor around the core gameplay loop.

[vegetablepotpie]

Are there ways to work without quantifying things? Sure. However, anytime you want to systematize something, you need to quantify them.

Still, the GP wants to know if there are ways of working without assigning “arbitrary” points to stuff, i.e. systematization for its own sake. You can certainly quantify things in a meaningful way for your problem.

While scrum and SAFe may be the right approach when working to find a technical fit to a customer problem, where estimates of “complexity” linearly map to some unit of time (conversation factor). These agile implementations fail completely whenever there are non-trivial, system level, non-functional requirements to satisfy. If you don’t have a platform supporting your work, and you’re in the act of building it, you’re no longer doing programming, you’re doing engineering.

In this case, the “systematization” that can be adopted are knowledge based approaches. DoD systems engineering has adopted “knowledge points” as an approach, which ties work to capabilities, which can be utilized at a program level. Which capabilities you have achieved is a metric that demonstrates work, and ties to things you actually want, as opposed to made up metrics, like points, which really tell you how good you are at estimating, but nothing else.

Other approaches are priority based. If you’re in a more service based environment, where work capacity is constant and goals change, a kanban board can be used to limit work in progress and prioritization can be set by either a risk based approach or a using cost of delay.