That great, undulating howl that you heard earlier this week was Pivots, former Pivots, and Pivots in spirit, screaming at the sky. We each in turn heard, and howled as we heard, that the priority field has come to Pivotal Tracker. Our jewel. Our refuge. Our little shelter in the JIRA-blasted wasteland.

The priority field is on every story. Though it can be disabled now, when it first launched last week it couldn’t be turned off. It defaults to “3 - Low Priority.”

If you’re just hearing this now, I’m sorry.

Now, you might be thinking, “Wow, Nat. It’s just a field you don’t like. What’s all this about howling?”

Tracker already has a simple system for determining priority: The order of the backlog. Position in the backlog is priority.

Ask in the presence of Tracker, “What priority is this story?” and it asks back, “What will you work on next?” Tracker helps a skilled operator guide a team away from managing fields in a database, and towards making decisions. Towards, especially, decisions that lead to working software.

What does it mean for a story marked “Priority 0 - Blocker” to be at the bottom of the backlog, blocking nothing? What does it mean for a “Priority 3 - Low” story to be above several “Priority 1 - High” stories? Before the priority field, such contradictions were impossible.

The priority field is a sign that Pivotal Tracker has been separated from the practices it was designed to support, separated from the philosophy it was designed to embody, and separated from the consulting organization that once attempted to teach those practices and that philosophy. It has been separated nominally, separated chronologically, separated physically, separated conceptually, and separated spiritually.

Take a look at the team’s own post explaining the new ‘priority field in Tracker. Take a close look at the first paragraph.

Have you struggled to manage story importance in your projects outside of the regular backlog priority order? Are you using other project management tools that handle priority differently and need a way to represent that information in Tracker? Do you have reporting needs that rely on more priority/importance information than what the backlog order provides?

Reporting. That's why Tracker has the priority field.

If you read on, you'll see several mentions of "a lot of feedback," and a promise to update the blog article "as more feedback is received and adjustments are made." They appear to have been surprised by the reaction many people had to this change – surprised by all that howling.

If external reporting requirements demand a priority field as the price for using Tracker, well, there are stranger and worse options in Tracker’s settings already. But the priority field was only, belatedly, made optional, and is still on in new projects by default.

Have you struggled to manage story importance in your projects outside of the regular backlog priority order?

If you struggle to manage story importance, you are struggling to make decisions. The old Tracker asked you to face this problem head on.

What are these “reporting needs?” What human purpose do they serve? The blog post from the Tracker team contains not one human scenario, not one human need. “Reports.” “Sorting.” Why?

There is much “I want to…” and no “… so that…” Does the Tracker team even use Tracker itself anymore?

All classifications are false, but one way to categorize stories that I find useful is the following:

• Those that we will work on next
• Those that we will work on soon
• Those that we will not work on, but that we imagine that we will work on
• Those that we have decided not to work on

A priority field invites us to spend moments of our one precious life on items in the third category. The ordered list invites us to spend our time on the first and the second.

“Position is priority,” says the ordered list. “Spend most of your time on the work the team is actually doing. Spend the rest of your time on the work that your team is about to do.”

The developer asks, “What should I do next?” The ordered list says, “Whatever is at the top of the list.” This is why the developer loves Tracker.

There is only one “next” in an ordered list. “What should we do next?” is a question that remains answered. The simple gravity of the ordered list provides the answer, always.

There is no limit for the number of objects that can be assigned a “P1 - High” priority. Nor could there be. There are 5 positions available in Tracker’s new priority field. Are we meant to have only 5 stories?

The developer asks, "What should I do next?" The priority field says, "I don't know, ask your manager." This is why the developer hates JIRA.

Ah, but I can hear you saying, “A practitioner might pick up a story from deep in the backlog! They might lack the knowledge or skill necessary to work on what is at the top of the backlog, and choose a story that they can work on instead. This destroys priority information. A priority field is necessary, to preserve the intended priority.”

I ask, in return, “What good is old priority information?”

Once a team starts a story, it must be finished, or discarded. Otherwise, it will hang around, flapping like the dead half-thing that it is, sucking the vital blood of any other story unfortunate enough to be worked on with the dead story still in progress. Teams can be driven mad by too many of these hungry ghosts. They must fed, and be laid to rest quickly. A static priority field, unresponsive to context within a backlog, obscures the reality that the team is always working on the most important work.

It is the 11th law of complex systems: “Actions at the sharp end resolve all ambiguity.” If a practitioner picks up a story, that act makes it the team’s priority. If you want to ship working software in a timely fashion, you must accept this. You cannot cling to the imagined priority that a static field offers.

This is one spot, incidentally, where the Scrum people have it right. They say, explicitly, that it’s not a prioritized backlog. It’s an ordered backlog.

“Priority” confuses us. We want to call everything “high priority.” We confuse “priority” with bigness. We put all the hard important work at the top of the backlog, and the work that would make the work easy work at the bottom. We waste hours on categorization, on filing, on reports that no one will read. We waste whole lifetimes carefully documenting ideas that will never be implemented.

All that confusion is now at the center of every Tracker story, below the story type and above the estimate.

The question, “What priority is this story in itself, independent of other stories?” is a “question that tends not to edification,” like the metaphysical questions in the Buddhist parable of the poisoned arrow.

Thích Nhất Hạnh, in Zen Keys, tells that story this way:

The Buddha always told his disciples not to waste their time and energy in metaphysical speculation. Whenever he was asked a metaphysical question, he remained silent. Instead, he directed his disciples toward practical efforts.

Questioned one day about the problem of the infinity of the world, the Buddha said, "Whether the world is finite or infinite, limited or unlimited, the problem of your liberation remains the same." Another time he said, "Suppose a man is struck by a poisoned arrow and the doctor wishes to take out the arrow immediately. Suppose the man does not want the arrow removed until he knows who shot it, his age, his parents, and why he shot it. What would happen? If he were to wait until all these questions have been answered, the man might die first."

Life is so short. It must not be spent in endless metaphysical speculation that does not bring us any closer to the truth.

Tracker no longer remains silent when we ask, “What priority is this story?” It no longer guides us back towards the practical effort of deciding what to work on next.

Life is so short. It must not be spent in endless metaphysical speculation that does not bring us any closer to working software.

The news part of the newsletter

As I mentioned last week, there will be one or two more issues of this "season" of Simpler Machines, and then this newsletter is going to go on hiatus for ~10 weeks. I'm going to be doing a bit of consulting, and will need to focus all my software thoughts on that for a bit. I also want to take some time to think about what "Season Two" should look like, refocus and reorient.

In the meantime, I'll be writing a much sillier newsletter over on Substack called If I Could Give It No Stars, I Would. It's going to be about strange and funny Google Maps reviews, and what that tells us about the deep human longing to be seen. I hope you'll subscribe.

Jobs

If you want to solve big, important, society-impacting problems with software, you could do a lot worse than Flexport. They have a bunch of engineering positions open, at all levels, and I like a lot of what I see there. "A love of simple, well-tested code" comes up repeatedly.

They came to my attention as the driver of what might be the most important thing that happened in the world last week: a huge bottleneck at west coast ports was partially alleviated when a rule about container stack height was temporarily lifted. Their CEO appears to understand systems thinking.