Most developers have experienced this during backlog refinement.
A GitHub issue looks straightforward. The requirements seem reasonable, the implementation appears manageable, and the team agrees on an estimate.
Then development starts.
Someone identifies a missing error state. QA raises an edge case. A security concern emerges. The Product Owner clarifies a requirement that changes the scope entirely.
Suddenly, that five-point issue looks considerably more complicated.
The problem isn't necessarily poor estimation. It's that we tend to evaluate requirements through the lens of our own experience.
What happens when we deliberately look at the same issue from different professional perspectives?
Imagine a GitHub issue with the following requirement:
Allow users to update their notification preferences, including email notifications and in-app alerts.
As a developer, my immediate questions might be:
These are sensible technical questions.
But they aren't the only questions worth asking.
A UX Designer might focus on how users understand the available options.
A QA Engineer might consider what happens when a user changes preferences across multiple devices.
A Security Engineer might question whether users can modify another account's preferences.
All of these perspectives can influence the implementation, testing effort and ultimately the estimate.
This is the thinking behind the optional AI review profiles in Pointwise, a GitHub-integrated Planning Poker application.
Pointwise uses GitHub Copilot to review an issue from a selected professional perspective.
Rather than asking AI to provide a generic assessment, contributors can choose a profile that influences which aspects of the requirements receive attention.
There are currently six profiles.
The Engineer profile focuses on technical implementation.
For our notification preferences example, useful questions might include: The objective is to expose technical assumptions and potential implementation complexity.
This is particularly useful when a requirement appears simple at the UI level but may involve several backend services.
Developers often receive requirements describing what a feature should do without fully explaining how users will interact with it.
The UX Designer perspective encourages questions about usability, accessibility and interaction behaviour.
For example: These aren't merely visual design considerations.
They can introduce additional states, components and acceptance criteria that affect development effort.
A technically complete implementation isn't necessarily a useful product feature.
The Product Owner profile considers requirements in terms of user value, scope and intended outcomes.
For our example: This perspective can reveal requirements that are either missing or unnecessarily broad.
Sometimes the most valuable discovery is that the team can deliver a smaller, more focused solution.
QA engineers are particularly good at identifying situations that aren't covered by the happy path.
Consider the notification preferences feature.
What happens if the API request fails?
What if the user submits changes twice?
What if preferences are modified from another device?
What happens when an existing user has no saved preferences?
The QA Engineer perspective encourages examination of edge cases, validation, error handling and testability.
These questions matter because unexpected behaviour doesn't become cheaper to address simply because nobody mentioned it during refinement.
The Business Analyst profile looks at requirements, business rules and dependencies.
It can help identify ambiguity between what stakeholders expect and what developers believe they're implementing.
This perspective is particularly useful for enterprise applications where seemingly isolated features often interact with wider business processes.
Security requirements can be overlooked when the discussion focuses primarily on delivering functionality.
For notification preferences, a security-focused review might ask: Not every issue needs a lengthy security assessment.
But identifying an authorisation problem before development is considerably better than discovering it after release.
There's an important distinction between using AI to review requirements and allowing AI to determine how much work something involves.
AI doesn't necessarily understand the complete codebase, the team's experience or every architectural constraint.
It can also misunderstand requirements or raise concerns that aren't relevant.
That's why I see these reviews as additional perspectives rather than authoritative answers.
If an AI review suggests that a database migration might be required, the team should verify whether that's true.
If it identifies an accessibility concern, developers should evaluate the actual interaction.
The value comes from prompting useful conversations, not blindly accepting generated recommendations.
In Pointwise's collaborative Planning Poker workflow, contributors estimate independently before their scores are revealed.
The team can then discuss differences and reach consensus.
An optional Copilot review provides another way to examine the issue, particularly when requirements are unclear or contributors have identified competing assumptions.
For example, a team might initially estimate five points. A QA-focused review could raise several missing error states.
After investigating those concerns, the team might decide the original estimate remains appropriate, or that the scope needs clarification.
Either outcome is useful.
The AI hasn't replaced the team's judgement. It's helped the team ask better questions.
I've built these review profiles into Pointwise to make it easier to explore requirements from different perspectives without leaving the GitHub issue and estimation workflow.
The walkthrough below demonstrates the collaborative estimation process and optional Copilot review.
Watch the Pointwise walkthrough on YouTube Software estimation isn't just about understanding how difficult something will be to code.
It's about understanding the work well enough to make an informed decision.
Engineers, designers, testers, product owners, business analysts and security specialists all approach requirements differently.
Those differences are valuable.
AI review profiles offer a practical way to introduce additional questions into refinement, especially when every specialist isn't available for every discussion.
But the responsibility for evaluating those questions must remain with the team.
The goal isn't to let AI tell developers what they've missed. It's to help developers discover what might be worth discussing before implementation begins.
Which perspective tends to uncover the most unexpected complexity in your team's requirements: engineering, UX, QA, product or security?