Professor Beekums Blog


Follow Professor Beekums
follow professor beekums on twitter add the professor beekums rss feed

Users Don't Care About Your JIRA Board

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.

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.

share on twitter share on linked in share on reddit share on facebook
Hi there! I hope you enjoyed this post.

If you did, I'd appreciate it if you took the time to check out my product: Dynomantle

Do you struggle with organizing notes, thousands of bookmarks, emails, or other digital stuff? Do you feel bad because you can't copy the habits of "productivity gurus"?

Dynomantle can help. It is a knowledge management tool designed to work with your existing habits. You don't need new habits. Dynomantle works around you rather than have you try to force yourself to work around a tool.

Signup for free!
Sign up for the Professor Beekums newsletter for updates on new posts!
Close this