How many JIRA tickets should you complete each week as a software engineer?

Over the past 7 years of my career I've worked with and mentored dozens of engineers across various teams, orgs, and companies. A common pattern of stress / anxiety in newcomers to teams (whether junior or senior) is how to measure how well they're doing.

A lot of companies use JIRA for task management and I often see / hear task velocity thrown around as a potential measure of their success (a la burndowns, review cycle data, etc). I recently had another chat where this came up (and most of my posts are ways to crystallize and scale my views on things) so here I wanted to give my thoughts on the matter and answer the question:

"How many JIRA tasks should you be doing each week as a software engineer?"

What is a JIRA ticket?

First we need to talk about tickets.

At its core a ticket is really a todo item - a task. Yes there are different philosophies around ticketing so yes what exactly this is will depend on how your org / team does this - it may be a user story, a problem to solve, a todo item to cross off etc. But at the end of the day we made a ticket to remember to do something - so basically it's a task on a todo list.

This is important to call out because tasks vary widely in scope and impact.

1 task could take you longer than 100 other tasks
1 tasks could be more useful / impactful than 100 other tasks

Many orgs have ways to try to measure and label these dimensions w things like points and priorities but they are largely proxies so often are misaligned one way or another.

The key thing to take away from this is - each ticket is a task and not all tasks are created equal.

What does it mean to be successful in your position?

Okay so what does this task definition mean for you and your career as a software engineer? Well we kinda need to break down what success means in order to see how we can leverage these tasks for success.

In general there are usually two perspectives of success playing out wrt tasks in a company:

Business - Trying to hit their quarter goals and they enlist task trackers to try and observe progress

Generally the business doesn't care about tasks, they care about outcomes - are their problems / goals being achieved on time

Career - You are trying to do good work and progress in your career (maybe titles, money, prestige, or smth else)

Generally those rating you for career progress do care about tasks - as a proxy for effort and (misguidedly) impact

Ideally both of these perspectives would align because logically they both should want the same thing - success of the business. Thus logically the better you help the business succeed the more valuable you are and thus the more you should be rewarded / progress in your career.

Anecdotally that is often not the case - there are misalignments in incentive structures and the soul of the idea (helping the business succeed) gets lots in the layers of management telephone.

What this means for us is that we often need to manage our own careers and frame our accomplishments to fit the definitions of success of both perspectives if we want to progress - it's unlikely anyone else will do this for you.

Succeeding from the perspective of the Business

The Business perspective is often the most logically aligned with incentives. This is because our whole job is to fulfill a role the business needs to succeed and thus it makes sense that our efforts should always be aligned towards that success.

Generally the business cares about moving their KPIs, hitting their quarter goals, and meeting intermediate deadlines. This is often set from top-level initiatives and teams have varying degrees of freedom for how they try to fulfill those goals.

For the most part this means the Business does not care about how you manage tasks. Yes they want to have a high level view on if things are going well or not (and how they can fix it) but generally they don't care ab the size of your epics or the velocity of your tasks / PRs.

The business just wants to make sure that their numbers are moving in the right direction, their initiatives are on track, and their deadlines are being met. This means that they do not care if you spent 1 hour vs 100 hours on that problem or if you finished 1 task vs 100 tasks to get it done - they just want their asks completed.

So my advice to succeed from this perspective is:

Focus on org and team goals - these are the main things, this is the definition of impact.
Manage expectations early and often - when other things inevitably pop up, discuss priorities w stakeholders and drop the things that are not priorities. You will not get credit for this extra stuff and if it makes you miss your main priorities it will be seen as a negative not a positive.
Make your accomplishments visible - The business won't understand / care ab low-level details nor will they take extra effort to understand how what you've done impacts them. So it's up to you to make your accomplishments visible and frame them in a way that they understand - usually using language like KPIs, goals, business / customer unlocks. Share your accomplishments broadly and put it in language the whole business will understand.

Succeeding from the perspective of your Career

Whatever your goals for your career, generally you want to get good+ ratings in your current role. It would be nice if just succeeding from the biz perspective were enough but unfortunately it largely isn't.

This is for a lot of reasons but largely it's:

Lack of visibility into impact
Quest for holistic, comparable measurement for easier ratings
Easy access to process-based measurements

So often orgs resort to using proxy measures from their process tools to make "data driven" decisions which often over-emphasizes outputs vs outcomes (impact).

Tasks / points completed
Lines of code / # PRs / # comments
Weeks-of-work completed (based on estimates) / Quarter line items completed

Often these are accompanied by and colored with cherry-picked situational anecdotes that your reviewers happened to be a part of:

leading a meeting well / poorly
finding / solving a particularly hard bug
Taking initiative to do x (or failing to do so)

All these regardless of the resulting impact / context with the general goal being to answer a few more subjective questions:

Are they a dependable teammate?
Are they working hard?
Are they doing good work?

Together this paints a general picture of how you're viewed career wise and is largely what ends up in your peer and up/down reviews. The problem of course is that each one of these proxy measures is itself flawed and while sometimes taking a mean of many proxies can lead to a greater understanding of the whole I think more often bad data leads to bad decisions.

But this is the reality of how these things work and so you kinda gotta play within the bounds of this game. That said I think there are ways to play the game such that you largely get to focus on what matters (business impact) and avoid the politics and still achieve positive outcomes.

So my advice for succeeding from this perspective is:

Observe team / org norms and fit into that - task size, task velocity, what is rewarded, what they consider "best practice", how they track and share progress
Always show progress - Always be completing some tasks each week. If this means you need to break bigger tasks down into smaller ones then do that.
Work with your manager - Your manager is your most direct connection to the review cycle - they are the primary filter for ratings and promotions and have the most perspective on what success looks like / how you match up to it. So work w your manager to see how you're doing and make plans to do better.

How many JIRA tickets should you be completing each week?

So now we kind of have an idea of what these JIRA tickets mean and what success often looks like from a few of the important perspectives that factor into your career success (though these can and will differ from org to org). Now let's try to answer our original question of how many tickets you should be completing each week.

So from our two primary perspectives the general answer is:

Business - Cares ab solutions to their problems not how you do it -> tickets don't matter

Career - Often cares ab tickets because those are easily measurable and they don't have a better measure -> tickets do matter

So my Simple Scalable System for managing these is:

Focus on Impact - At the end of the day you were hired into this role to help the Business. So the north star is to make the business succeed by accomplishing your org / team goals. Everything else is secondary. Short-term this may negatively impact you because #misalignedincentives but long-term this is better overall - for your team / org, for your career at the company, and for your overall career in terms of resume builders. Short-term you may have bad teams, orgs, and leaders who do not see it this way but largely they get moved out - it just might take a few halves (and you can move to a better team / org yourself to get away from them).
Make Visible Progress - All you can do is your best. What most ppl care about is you're being a dependable worker who is making progress on their priorities. That said you will need to make sure that you are making this progress visible - invisible work does not get rewarded and often gets penalized. So track the work you're doing, make it visible (tickets, PRDs, chats, etc), and publicize when milestones are achieved (messages to stakeholders, company announcements, logs on your self eval sheet, etc).
Get regular feedback - Check in with your manager, stakeholders, and project collaborators regularly on your priorities, plans, and anything that could go better. Long term this is how you grow as an engineer and short term this can help you course correct before your next review cycle.

In practice this means you should be completing at least 1 ticket each week, often closer to 3-5. This measure is largely useless cause context matters so really it matters more that you are doing a reasonable amount compared to your peers. That said if you are not at least doing this much / near the relative average then that's a sign you should think about why - maybe you aren't following best practice / framing your work efficiently.

So those are my thoughts on JIRA ticketing and more broadly framing the work you're doing so that you actually get credit for them from the business and career perspectives. Take all of this with a huge grain of salt though as YMMV and sharing these tactics directly may get you in more trouble than they help you.

This is all just my personal experience - I am not good at politicking / ladder climbing, I have a deficit of decorum, and my views often get me in trouble when my logic doesn't match w cultural norms. But this is how I view things, how I've tried to balance my craft w its career, and how I've gotten where I am today so hopefully it's more helpful to you than not.

Q: How do you think about being successful in corporate environments? What are tactics you use to be successful at your job and in your career?

If you liked this post you might also like:

Want more like this?

The best / easiest way to support my work is by subscribing for future updates and sharing with your network.