I’m going to start this off by saying that I think JIRA is an ok tool. Good project management requires some visual tracker on progress. Most people are visual thinkers and while daily standups are great communication tools for getting project status, they are more effective with some visual such as a JIRA board.

The problem is when we start to over-value the JIRA board. The problem is when we treat the JIRA board not as a tool, but as an end goal.

Every conversation starts to be about “how many tickets did we complete today?” or “how many story points did we complete this sprint?” or “how close are we to our estimates?”. The success and failure of the team starts to get measured by the answers to those questions.

We start to lose sight of what the real end goal for software should be: being useful to someone.

Your users don’t care about what’s on your JIRA board. They care about whether your software is making their lives easier or providing value in some other way.

One would think that every task that goes on a JIRA board should be providing value to users in some way. The thing is: stories, tasks, etc go on the board with the intent that value to the user will be provided.

What we intend and reality don’t always align. Things come up during implementation. Maybe some other high value opportunity presents itself. Maybe another team needs help with something that is more important. Maybe what we’re working on isn’t going as well as planned (e.g. it is failing user acceptance testing).

In all of these situations, the right call should be to adjust the board to reflect new priorities that maximize how useful our software is. Our original intentions were just a hypothesis on the value provided by a task.

Well said. It's a common misconception that things like "# story points completed" or "# features shipped" or "# lines of code written" are synonymous with real value.

Each feature is a hypothesis for delivering value.

— Mike Cavaliere 🧠💻 (@mcavaliere) March 15, 2022

If that hypothesis proves false, we need to adjust. However, teams will often obsess over the state of the JIRA board as it was when a sprint started. Changing it mid-sprint would affect the metrics! Everyone decides to continue charging at the original goals even though those goals aren’t the right ones for the product.

There’s no real benefit to this, other than making a project manager or engineering manager feel better. Users don’t care what your sprint goals are. They care about what your software can do for them. Every conversation around priorities should be focused on that.