Let's be honest from the outset – project management tools like JIRA, YouTrack, and Monday.com are brilliant for keeping development teams organised. Most of us process information visually, and while your morning stand-ups might be grand for communication, they're infinitely more effective when paired with a proper task board.
The issue arises when we begin to worship at the altar of the almighty board. When the colourful cards and neat columns become not just a means to an end, but the end itself.
You know you've crossed this line when every conversation with your team revolves around metrics rather than meaning: "Have we cleared all the tasks in the sprint?" "How many story points have we burned through this fortnight?" or "Are we bang on with our estimates?" Your team's success starts being measured solely by these arbitrary numbers, and that's where things go pear-shaped.
We lose sight of the fundamental purpose of software development: creating something genuinely useful for someone.
Your clients – whether they're pensioners using your banking app in Norwich or retailers using your inventory system in Kelso – couldn't give a toss about what's on your JIRA board. They care about whether your software makes their day easier or provides value to their lives.
Theoretically, every task that lands on your board should deliver value to users in some way. Stories, epics, and tasks are added with the intention of providing that value.
But as anyone who's spent time debugging knows, intentions and reality rarely align perfectly. Circumstances change during implementation. Perhaps a more valuable opportunity presents itself unexpectedly. Maybe another team at your company needs assistance with something more pressing. Or, what you're working on simply isn't passing muster with the users (failing acceptance testing, as we politely call it).
In all these scenarios, the sensible approach would be to adjust your board to reflect new priorities that maximise usefulness. Our original plans were merely hypotheses about the value of certain tasks.
If that hypothesis proves incorrect, adaptation is necessary. However, teams often become obsessed with maintaining the board exactly as it was when the sprint kicked off. Making changes mid-sprint would skew the metrics! And so everyone continues to pursue the original goals, even when those goals no longer serve the product or its users.
This approach has no real advantage beyond making a project manager feel accomplished during their quarterly review. Your users don't give a monkey about your sprint goals. They care about what your software can do for them. Every conversation around priorities should focus on that central truth.
Our most successful projects have used a straightforward spreadsheet with simple priority levels (low, medium, high), ensuring clients clearly understand the business cost-benefit relationship of each task. From there, we use our internal project management tools, but maintaining clarity for the client remains paramount.
Remember this the next time you're tempted to celebrate completing all your story points despite delivering nothing of actual value: Your customers don't care about your JIRA board – they care about results.