Ah yes the forgotten land of uncompleted tasks. Slated to be a hotfix when it becomes a problem.
Everywhere I’ve ever been,
If it’s lower than “High” or “2”, it’s as good as “backlog” :)
(There can never be a priority “1” and seldom “Highest”, never “Blocker”, otherwise the CEO gets a text or something.)
At every company I’ve worked at there were basically 3 priority levels - normal, stuff the client says is urgent, and the stuff that’s actually urgent. “We’ll fix it later” is basically for the week in December that everyone’s on vacation and the juniors have nothing to do.
Lol, I love that week. Feels so productive working on low priority shit that’s been around forever
Refactoring that parser you did for the internal DSL in 2011.
Scrum Master: “Do we really have to make it a blocker?”
Me: “Uh yeah. It’s blocking these three other tasks.”
Scrum Master: “But is it really?”
Me: “Yes.”
Scrum Master: “Let’s just leave it on in development and we can review the progress tomorrow.”
Me: “That’s what you said yesterday.”
Scrum Master: “Alright guys. I’m going to give you back five minutes of your time today.”
Holy shit that’s too real. I come here to get away from work!
Don’t forget breaking everything up into ever-smaller tasks just so that something, anything, can be closed every day. 😂 Because the process matters, not the work.
Backlogs are great. Sometimes while working on prioritized tasks the depriorized backlog tasks are made irrelevant and thus you never have to do them and you don’t waste effort. Call it strategic deprioritization or perhaps even tactical laziness.
Yet the solution is so simple. Let the them spend 20 – 35 % of their paid time on backlog. Let them refactor the architecture. Let them improve the code base. You know, that thing the Lean book talks about, the part that everyone overlooks, the part so critical yet so often overlooked that others wrote books that ride that one aspect home. Oh, unless you want them to spend overtime on a production problem whose root cause a scrum master added to the backlog 5 years prior to the incident, of course. Oh, unless you want them to give you one year estimates for changes as simple as translation changes 'cause the architecture is so ass-backwards and never improved upon that everything depends on everything and everything breaks with one simple change. And who needs tests, right? Waste of time and money! Just live in fear that one change can break the entire software, like a real man.
Yet the solution is so simple. Let the them spend 20 – 35 % of their paid time on backlog. Let them refactor the architecture. Let them improve the code base. You know, that thing the Lean book talks about, the part that everyone overlooks, the part so critical yet so often overlooked that others wrote books that ride that one aspect home.
But why do that when instead you can just pretend those issues don’t exist (or simply fail to understand them) and secure a bonus/promotion/personal favour by cutting “unnessecary” labour costs then celebrate by burbling on about how capitalism “maximises efficiency”.
Ummm yeah it will be in “Phase 2” of the project.
My longest lived backlog task is 3 years old
Those are rookie numbers!
Somehow their company is only 2 years old 🤔
I completed a ticket made in 2011 today!
We let a bot close our backlogs after 60 days of inactivity. It has a valuable “get it done or let it go” effect.
Honestly why do jr devs want to do work so bad, I’m literally just like “yo chill” and they keep pestering me for work
They probably spent a year looking for a job and they’re suffering from imposter syndrome so they feel like if they aren’t constantly getting stuff done they might be fired, plus they haven’t worked enough to hit burnout and don’t know how to pace themselves.
This
Or, possibly, that? Who knows.
That seems rather unreasonable.
ugh Jira. At my first job in 2006 I was the Jira administrator. Every project wanted their own custom fields. We had a Jira project for “infra” problems it had 3 fields yall Title/Description/priority and it worked so well. Moved to a company with a simple ticket system with not much more but the concept of “tags” it was heavily
“I archived them all Padme. They’re gone…every single one of them. And not just the minor tickets.”
But the stories and epics too
That’s why scrum teams need aggressive POs and scrum masters.
No matter how aggressive PO & SM are they don’t get to decide priority.
Yep. Gotta clean out that backlog by deleting the stuff that will never get done.
IMO it’s good to have a “shadow backlog” for stuff like this. Keep the actual backlog for prioritised product work, “ideas” and tech debt can be kept in GitHub Issues or even just a wiki page somewhere.
I have two levels of backlog. The first level is my curated list of tickets that are highly worth doing in the near future and is limited in size. It’s currently larger than I’d like at 30-something (for a team of a little under 10), but I’m trying to get the team to focus on it more after historically neglecting it.
The second level is literally just everything else. Hundreds upon hundreds of tickets, ranging from restructuring unit tests (which will frankly never happen unless the structure of the tests somehow became a major barrier) to cool features that just aren’t important enough yet (or would take too long). Plus all the super low risk bugs, often in edge cases that nobody really cares about yet or aren’t worth the time to fix yet. And then there’s all the automation style tickets about improving the handling of something (commonly edge cases of things already automated for the happy path), but often that something just isn’t common enough to be worth it.
Tickets in the second level sometimes do get done. Usually because some issue becomes more common, enough people ask for it, or we simply finally have time for a new feature (can only do so many of those at a time). A common theme I have is I’ll encounter a problem, file a ticket, then eventually encounter the problem enough times that I go, “fuck it, I’ll do it myself”.
This is the way 🤝
Meh, I prefer to call it trash. What’s the point of a backlog nobody works on, and so hopelessly irrelevant that the issues themselves may no longer exist or are otherwise outdated?
Because then when someone else suggests the same thing you can say that its in the backlog 😉
