I find it annoying that our new engineering manager adds tickets for things like “started to send an email,” “attended a meeting about performance review,” and “updated the team Confluence page.”
Despite my best efforts, they persist in tracking any tasks lasting longer than 15 minutes.
What would you do to fix this? Is it genuinely acceptable to add tickets for non-product development to the backlog?
In general, the anticipated overall sprint capacity should account for time spent on administrative tasks. Administrative tasks often take up 10–20% of an employee’s time, depending on the organization. Therefore, 32 hours may be designated for the sprint task if there are 40 hours of work per week.
I encourage engineers to add subtasks to sprint items as they are identified and to aid in documentation, but typically this does not lengthen the duration of an item; rather, it just results in more thorough documentation.
An old proverb states that you should never correct someone you disagree with when they make a mistake. Not that you should be at conflicts with this individual, but since it’s their behavior and mistake and it won’t actually hurt you, I’d advise you to just let it go and let them to act foolishly until they realize their mistake and stop. It won’t be simple to persuade them to change because you’ve already asked them to do it and they still persist in doing it.
It could be worse, though, as I once worked with a dev VP who created separate tickets in separate projects for each group. For example, UX had a ticket in the UX project, while dev worked on implementing that spec in a separate ticket in the dev project and QA conducted their testing in a separate ticket in the QA project. I despised that person.
30% of my EMs’ work is their work, 70% is mine. How they track it doesn’t matter as long as that 70% is finished.
I struggle with the same problem, and I genuinely believe it’s beneficial for people to monitor whatever work they must perform in order to make it apparent, but as a product, it goes without saying that we need to manage a product backlog. This problem is resolved by giving the product complete authority over user stories, while allowing the rest of the team to construct tasks and subtasks to handle their own duties. Jira’s quick filters make it simple to filter only by user stories.
They shouldn’t be placed in a backlog. This seems like time tracking, which is possible within Jira itself by using Tempo. Ask him to investigate it. It’s actually fantastic to get reporting on how engineers use their time and how much time they actually spend in meetings because Tempo is good at bucketing these jobs.
The backlog is more for the engineers than for the leadership, product, or design teams.
I wouldn’t mind if someone wanted to report everything as long as it didn’t affect engineering capacity or morale.
It must be demonstrated (via feedback from engineers, decreased output, or during a review period) if it begins to do either of those.
According to my personal experience, competent product managers devote very little time on Jira, and as long as they can maintain control over prioritizing, they give absolutely no advice for how EMs ought to carry out their duties.
Unpopular ideas will eventually die, according to a notion that, in my opinion, makes your life as a product manager lot simpler. It’s not necessary for you to kill them.
@BrandonMilne, I would also add that monitoring administrative processes in the EM makes it extremely simple to observe how they affect development time. If the team is wasting too much time in meetings, it can be a means to come to light. The organization may benefit greatly if he adds a tag or other mechanism to make it simple to track or filter the items. There is no reason to be outraged about this.
Who mentioned that? The product backlog is frequently referred to as a backlog. See what, for instance, the Scrum Guide has to say about this:
A Product Owner orders the work for a complex problem into a Product Backlog.
The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
Although the Scrum-specific roles are not commonly relevant, I believe that the concept is universally recognized:
The tasks needed for developing the product are listed in the (product) backlog. It must be ordered, and certain team members select the tasks that have to be completed.
Designers and PMs should collaborate on and in the backlog, in my opinion. How else would you know what work is scheduled and being done at any given time?
Hope you agree…
@PriyaVarma, OP (@CarlosDubois) is undoubtedly using the term “backlog” to refer to JIRA, as do the most of us.
For engineering, the Jira backlog is 100% accurate.
His EM isn’t adding administrative tasks to the product backlog. That would be ridiculous. He’s adding them to a sprint board in Jira, which is actually a sprint backlog.
You are aware of what is being worked on and what will be accomplished through planning, refinement, review, and retros. What would the point be if you weren’t there every day? Any unexpected delays or obstacles are communicated to you by your engineering manager.
@BrandonMilne, The JIRA backlog is not 100% there for the engineers. It’s really there for everyone that’s interested in what’s being built. Engineering uses it, QA uses it, and it wouldn’t even be there if a PM didn’t build it. Wow.
Do you, as a PM, create the entire Jira backlog? What?
Yes, we occasionally compose epics. Yes, we create feature requests, but are you actually creating all those tickets and adding the necessary information? debt from technology? changes to the infrastructure? Each and every task required to complete an epic?
You don’t sound like a product manager; you sound more like a product owner.
I am not a backlog manager, but I do develop documentation, engage with the team, manage stakeholders, set the vision, cheerlead, and own prioritization.
And why would anyone need to know what is being built by looking at the backlog? Why not simply inform the public of what is being built and when to anticipate it? Investigating the specifics of what your team is doing is it in anyone’s best interest? Do you let everyone wants to join your squad to stand up?
Regarding quality assurance, in my opinion, engineers that perform QA (testing, etc.), sometimes known as quality engineering, are engineers. They are not in the backlog if you are referring to non-technical QA. They rely on communication from either product or engineering and are in charge of a whole other queue.
7 years of experience in various teams and jobs here plus leadership.
You’re using Jira incorrectly if your backlog isn’t for your engineers.
I’m with you.
My business units agreed upon process is:
Engineers will write all the tasks they need to fulfill a story and then estimate and point them.
Provided I’ve written out the stories with clearly defined criteria, they’ll have no troubles adding the relevant tasks during sparring sessions.
When we do sprint planning and grooming, as PM I’ve presorted the epics to focus on for the next sprint and then it’s up to the engineering team to decide hoe much they can take into the sprint.
You must have worked at a medium to large company. I worked at a very small company. The epics and user stories were written by myself and my BA. The team added tasks.
And, I did all those other things, roadmaps, strategy meetings, stakeholder management, cheerleading and anything else I needed to do
@JaneWinfred, I’ve worked for startups with 8 to 500 people.
Despite the fact that I write epics and user stories, the majority of a jira backlog is made up of tasks to complete epics and user stories, as well as tech debt and bugs.
I simply don’t get how that makes Jira useful for anyone other than the engineers or how it would involve many PMs in Jira. Everything I enter into Jira is done to help the engineers organize their work and understand my priorities.
@CarlosDubois, sounds like your EM counterpart would be better suited to using Trello for admin tasks?
I have a simple; to do, doing, done Trello board to throw all these sorts of tickets onto so that I can track their lifecycle.
Much easier than creating full blown Jira issues just to set a meeting.
Perhaps the EM doesn’t feel like people think they’re doing any work and so this is a way to create visibility on that.
Resolving this issue requires effective communication and understanding between you and your engineering manager. While it’s generally preferred to focus the backlog on product development tasks, there can be legitimate reasons for including non-product development tickets as well. Here’s how you can approach the situation:
Remember, open and respectful communication is key in resolving such issues. By actively listening, expressing your concerns, and proposing alternative solutions, you can work towards finding a resolution that aligns with the team’s goals and maintains a productive work environment.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.