50 Performance Review Phrases for Business Analysts

This page collects 50 performance review phrases written for the day-to-day realities of a Business Analyst role, covering self assessments, peer feedback, and manager reviews. Swap in your own projects, stakeholders, and metrics where a placeholder appears, and adjust the tone to fit your organisation's style.

Self assessment phrases - achievements

I gathered requirements for [project] and translated them into documentation the development team could actually build from.
I identified a gap between what stakeholders asked for and what the business actually needed, and raised it before work began.
I ran workshops with [stakeholders or teams] that turned a vague request into a clear set of requirements.
I mapped out the current process for [process or system] and used it to identify where the real bottlenecks were.
I wrote user stories and acceptance criteria that reduced back and forth with the development team.
I facilitated a discussion between [teams] that resolved a disagreement over what a feature should actually do.
I caught a requirement that would have caused rework later and flagged it before it reached development.
I documented [process or system] clearly enough that new team members could reference it without asking me directly.
I balanced competing priorities from different stakeholders to land on a requirement set everyone could support.
I traced a reported issue back to a gap in the original requirements and helped the team close it.

Self assessment phrases - growth and development

I want to get better at pushing back when requirements are vague instead of filling in the gaps myself.
I'm working on validating assumptions with stakeholders earlier instead of late in the process.
I sometimes over-document requirements for smaller changes, and I'm learning to scale my approach to the size of the request.
I'd like to build stronger skills in [tool or technique] so I can support more technical conversations.
I want to get more comfortable saying a requirement isn't ready instead of passing it along as is.
I'm learning to balance the needs of multiple stakeholders without letting the loudest one dominate the requirements.
I could do more to check in with the development team mid-project to make sure requirements are still holding up.
I want to improve how I communicate tradeoffs to stakeholders when a request isn't feasible as described.
I'm working on asking better follow-up questions instead of taking a stakeholder's first answer at face value.
I'd like to spend more time understanding the technical constraints behind the systems I write requirements for.

Peer review phrases

They're one of the people I trust most to turn a vague request into something we can actually build.
They ask good clarifying questions before documenting requirements, which saves the team time later.
They're honest when a requirement isn't fully thought through instead of passing it along anyway.
They flagged a gap in [process or requirement] that the rest of us had missed.
They keep their documentation clear and up to date, which makes their work easy to build on.
They're fair when mediating between stakeholders who want different things from the same feature.
They follow up to confirm requirements are still accurate as a project evolves.
They explain technical constraints to stakeholders in a way that doesn't feel dismissive.
They've built strong working relationships with both the business side and the development team.
They've become someone the team relies on for questions about [process or system].

Manager review phrases - strengths

They consistently turn ambiguous requests into requirements the team can act on.
They have a good instinct for when a requirement needs more validation before it moves forward.
They communicate clearly with both stakeholders and the development team, which reduces rework.
They've taken ownership of [process or documentation] and improved its clarity over time.
They handle competing stakeholder priorities fairly and without unnecessary friction.
They document their work well, which has made it easier for the team to reference and build on.
They're dependable on requirements gathering and rarely need reminders about deadlines.
They've grown noticeably in their ability to handle ambiguous requests over the past review period.
They bring a level head to situations where stakeholders disagree on what's needed.
They've become a go-to resource for the team on [process, system, or stakeholder group].

Manager review phrases - areas to develop

I'd like to see them push back more firmly when a requirement is too vague to build from.
They sometimes take a stakeholder's first answer at face value, and could dig a bit deeper before documenting it.
I'd encourage them to flag scope changes earlier instead of absorbing them quietly into the requirements.
Their documentation would benefit from leading with the business need rather than the technical detail.
I'd like to see them check in with the development team more often as a project progresses.
They could be more proactive about surfacing conflicting stakeholder priorities before they become a problem.
I'd like them to build more confidence pushing back on unrealistic requests rather than trying to accommodate everything.
Their requirements work is solid, and I'd like to see them build a stronger grasp of the technical constraints behind it.
I'd encourage them to take more ownership of [specific process] rather than waiting for direction.
They tend to over-document smaller requests, and could scale their approach to match the size of the change.

Want phrases tailored to your exact role and focus area? Use the free AI phrase generator, or draft a complete review free.