One GitHub Issue, Six Perspectives: How AI Review Profiles Improve Software Estimation
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?
One issue, several interpretations
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:
- Does an existing API support these preferences?
- Where will the settings be stored?
- Can we reuse the current settings components?
- How should the frontend handle failed requests?
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.
Introducing review profiles
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.
1. Engineer: Is the implementation understood?
The Engineer profile focuses on technical implementation.
For our notification preferences example, useful questions might include:
- Are existing services and components reusable?
- Does the change introduce new API contracts?
- Are database changes required?
- What dependencies could affect delivery?
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.
2. UX Designer: Does the experience make sense?
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:
- Can users understand the difference between notification types?
- Is it obvious when their preferences have been saved?
- What feedback appears if saving fails?
- Can keyboard and assistive technology users operate the controls?
These aren't merely visual design considerations.
They can introduce additional states, components and acceptance criteria that affect development effort.
3. Product Owner: Are we solving the right problem?
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:
- Why do users need notification preferences?
- Which notification types are included in the initial release?
- What should happen to existing users?
- What constitutes successful delivery?
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.
4. QA Engineer: What could go wrong?
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.
5. Business Analyst: Are the requirements complete?
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.
For example:
- Are notification defaults defined?
- Do different user roles have different permissions?
- Are there business rules governing mandatory notifications?
- Does changing a preference affect other application workflows?
This perspective is particularly useful for enterprise applications where seemingly isolated features often interact with wider business processes.
6. Security Engineer: What are we exposing?
Security requirements can be overlooked when the discussion focuses primarily on delivering functionality.
For notification preferences, a security-focused review might ask:
- Can users modify preferences belonging to another account?
- Are API endpoints properly authorised?
- Could sensitive information appear in logs?
- Are changes validated on the server?
Not every issue needs a lengthy security assessment.
But identifying an authorisation problem before development is considerably better than discovering it after release.
AI should challenge assumptions, not make decisions
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.
Where review profiles fit into Planning Poker
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.
See Pointwise in action
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
Final thoughts
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?
