Ah yes the forgotten land of uncompleted tasks. Slated to be a hotfix when it becomes a problem.
And one that requires several people to give up a weekend, too.
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.
I don’t know when this meme was originally made, but my boss unironically has this taped to his office door, and it’s glorious
I’m a Senior developer, and I’m still playing the part of the Junior in this meme.
I hate it when people insist on leaving their trash lying around where I work.
Ummm yeah it will be in “Phase 2” of the project.
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.
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.
Good for you. My oldest backlog task is from 2012. And that was imported from the previous ticketing system (AKA an Excel Sheet).
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.
Yeah as a junior this is accurate
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
Ah, but is this a double blocker or a triple blocker?
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.
That’s why scrum teams need aggressive POs and scrum masters.
I’m the Sr. Dev in this meme.
I usually just do this when a jr has fallen in love with a piece of work and wants to keep polishing it. They start to confuse “I could do X” with “I should do X”… And confuse “less than perfect but still acceptable” with “bug”.
I tell them to slap it on the backlog and to move on.
We have backlog grooming meetings every few weeks. If they still actually want to do it, we can talk, but like 19 times out of 20 they’ve found a new shiny rock by then anyways, and we’re now in a position where we can both agree it isn’t a good use of our time, and close it out as a “will not do”.
You don’t need aggressive POs or scrum masters to operate as a pragmatic team. I far prefer having a lean overhead. When there are more people shouting directions than people actually coding you’ve got too many cooks.
It’s interesting how people have different interpretations of mwmes. You took it as a reflection of a perfectly normal good thing, while I took it as a perfectly normal bad thing.
Iny experience, “put it on the backlog (and never look at it again)” is the response to someone raising a serious architectural problem.
Yeah exactly. I think you hit the nail on the head with the “(and never look at it again)”.
It’s not explicit in the meme. “Not doing it” and “never look at it” are totally different things… But I think you’ll fill it in based on your personal experience.
I’m sorry your backlog doesn’t get regularly revisited.
If I were you, I’d push for setting aside time to get it under control.
If your backlog is gigantic, I expect there will be pushback just because once the problem gets sufficiently large nobody is brave enough to broach it.
But, you can apply story slicing skills to these kinds of problems too. Break it down into smaller bits with clear and realistic objectives. Setting aside 30 minutes with the goal of, say, picking 5 items on your backlog that you know you won’t ever do because they’re super low value? Pick 5 items and close them off as won’t do. Baby steps.
I mean “imperfect” is a bug oftentimes. The other version of imperfect is “missing a feature”
Sometimes. Sometimes it’s just “I can refactor this to use X pattern”. Or “I COULD push X logic to some other layer”
deleted by creator
Yep. Gotta clean out that backlog by deleting the stuff that will never get done.
Our solutions architect is like this. Not because we’re working on anything important at the moment, but because we keep pushing back important upgrades further and further, making each day a more challenging operation to keep our rickety-ass distributed monolith alive.
We were supposed to upgrade from Java 8 on Springboot 2.1 to 17 on Springboot 3. That got wiped off the table because the bosses think shoving our inefficient solution into a cloud product is what will attract customers.
Do we work for the same company lol
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.
“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
