Your boss probably has no idea what you're doing or what you've done. This idea should terrify you: this person will determine the course of your career. If you want a raise or promotion, your boss will need to support it. The most natural person to promote is the person who's work they know best.
You might believe your boss should know a lot about what you do. Jira (or whatever software project management software you use) contains the complete history of your work. Git includes the work itself, in a convenient timeline. Also, you might even suffer a daily status meeting. No boss has a plausible excuse for lack of awareness -- but plausibility and reality often differ.
In my experience, many software managers have no idea what's happening on their team. They don't use their own tools, and even if they did, their awareness mostly focuses on what happens in the short term. I've had managers who misremember the recent past and insist on their own (easy to refute) version of history.
So how do you ensure your boss isn't at a loss for words during your quarterly review? You can write a weekly status report and email it to the key people in your organization. Now your boss has an easily-searchable record of your work.
When the time for promotions comes along, you can take your previous status reports and condense them into your achievements for that period.
The outline of a status report contains 5 items:
Your name is critical in case your boss shares or shows your report; you want to get credit. I typically send a PDF of my status report with my name prominently on the first page and in the footer of each subsequent page.
You will be cranking out status reports, so ensure the date of each update appears prominently. You don't want anyone to accidentally read your status from last year and get confused.
Work generally encompasses the actual activities you performed on behalf of your employer -- it shows that you're getting things done. I typically write one brief page for each item I worked on. The description targets a general audience and doesn't get too technical. Many engineers focus on the "what" and the "how" rather than the "why" when they report status. The most compelling status reports focus on the "why." Your boss probably cares more about the purpose than the implementation.
Your status report should transcend Jira or Git; you want a non-technical audience, like a typical director or vice president, to understand what you have achieved. Do not write, "Fixed a force-unwrap crash." Instead, write something like "Fixed a crash which prevented 1% of our users from successfully ordering a widget from us." Even better, focus on the business outcome: "Fixed a crash to improve widget conversion rate up to 1%."
While everyone dislikes crashes, businesses value increasing revenue. If you can, frame your work as adding value rather than promoting technical excellence. That might feel wrong to you as an engineer; you probably love technical excellence just as much as I do. While business leaders appreciate it, they don't necessarily understand it. Help them see the underlying business value of your work, and they might understand the business value of your talent.
The results of your work should have more prominence than your work itself. Sometimes your results relate directly to the past week's work, as in our crash example: fixing a crash unlocks more revenue. In those cases, the work and the (possibly expected) results are the same.
Also, a result can encompass a collection of work. Perhaps you redesigned four screens to improve the sales funnel. In those cases, you can present one result and several work items under that umbrella.
Occasionally your previous work will have a measurable outcome. That's a result. If you implemented a new UI last month, check on how it has changed user behavior. Have purchases gone up? More app installs? Better reviews? Congratulations, that's something you can mention this week to remind your boss of your previous work. Even if you wrote no code this week, you still might have results!
Results from previous work demonstrate a lot of value. You did work expecting that something improved, and now weeks later, you have proof that you achieved those results. Nice job! Show those metrics.
The final section of a status report looks into the future to uncover risks or new opportunities. Has an API deprecated? Will App Store rules change? Has some market opportunity been discovered? This is the section to mention it.
I create my status reports in Keynote by duplicating the previous week's file and updating the information. Keynote works well for this because it helps keep your text concise -- as you type more, the font gets smaller.
Keynote also makes it easy to add screenshots to help sell your work. Did you build a fresh new graph? Add a screenshot next to your text.
I export my keynote presentation to a PDF, and then attach it to an email to my colleagues across the company, including the CEO (I work at a small company). I time my status report email to arrive the evening before the weekly leadership meeting, which makes it easy to present the progress of the mobile team.