Working software is the primary measure of progress.
The entire purpose of the enterprise is to assemble software that the business can use to drive revenue. Towards that end, only working software will suffice. There are many byproducts of the software development process; lines of code, collections of tests, pages of documentation, processes, procedures, closed tickets, and more. None of these things matter. Only working software matters.
Some development teams will get hung up on other metrics. What is the code coverage? What is the developer velocity? What is the closure rate on feature tickets? How many defects per release? What is the cycle time? How many unit tests are there? What is the average cyclomatic complexity? The statistics are endless.
These statistics have a purpose. They guide the developers towards better development practices. They give managers some measures to determine the effectiveness of the team, both at the group level and at the individual level. The statistics have value within the development process.
All of this is secondary, though, to the ultimate goal. The team needs to deliver working software. Only through the delivery of working software will the business make money.
A related topic to this is the concept of “done”. For some, a ticket is “done” when they finish development of the story. For others, it’s done when it passes code review and enters the mainline. Maybe it’s done when they pass a feature over to QA. The problem with these is that the code is not delivering business value until there is working software in production. Since working software is the measure of progress, then a feature is not done until the software is in production, working for you.
Today's Card 