This is a commonly-used set of criteria for goal-setting. The trick is to be specific, but not overly specific ... and when possible to derive the goals from your manager's goals for the department. I'm not great at this either, despite several decades of working with such a system.
If you're being completely Agile, you may want to write these as rate-of-progress goals rather than endpoints. "Maintain an average cadance of N function points per sprint" would be specific, measurable, time-bound and hopefully you can pick an N which is attainable and realistic. Keeping the backlog under control (and preferably decreasing in size, or at least maintaining a somewhat predictable rate of removing things from it) might be another which could be quantified.
Remember that since your company is just starting this process, everyone is going to be flailing a bit on setting goals. Draft something, ask your manager to review it, rework it and iterate until it's good enough ... then turn it in, tack a copy on your wall as a reminder of what priorities you agreed to, and stop worrying about how well or poorly written it was. Yours will probably be no worse than anyone else's.
And remember that in the end, you aren't being graded on this document. You'll be graded on your work; this plan is just to help make sure you and your management agree on what your work is. They'd like it if you could predict your productivity accurately since that would help your management plan how much they can commit to in turn... and they'd like to see you stretch a bit, of course ... but if you over- or under-estimate your predicted results, that's really less important than what those results wind up being.
I don't know which flavor of Agile you're doing, but one of the points in the Scrum book is not to take the sprint plan too literally. Eventually you want to have a realistic sense of what your cadance, and the team's cadance, will be, but that only comes with time and practice... and if you over- or under-estimate, that's just a chance to look at why and whether there's an adjustment needed either to expectations or to permit better productivity.
As I said up front, I've been dealing with a system of this sort for quite some time. My experience with it has been that its value depends heavily on how willing your manager is to work with you to make it a worthwhile tool. It can become meaningless, timewasting ritual, or it can become a tool for discussing exactly what you need to do in order to get that bonus. It can be a tool for protecting you against being graded for something you weren't told was part of your responsibilities, but only if management works with you to maintain this as a "living document" which is edited when the responsibilities change.
In other words: If your management expects it to be a silver bullet, they need to be reminded that there is no silver bullet. If they're willing to use it as a tool to help you understand what you're being judged on, it may be useful.