Why I built Pointwise to help development teams make better-informed decisions during estimation.
We've all been in these estimation meetings
Someone presents a user story or GitHub issue.
There's a brief explanation of what needs to be delivered, a few questions, and then everyone is asked to estimate the work.
One developer thinks it's a three. Another thinks it's an eight.
A senior developer confidently explains why it should be a five.
After a bit of discussion, the team agrees on a number. Funnily enough, it's a five.
And everyone moves on.
But did we actually improve our understanding of the work, or did we just reach an agreement?
I've been involved in plenty of estimation sessions over the years, and I've started to question whether the way we approach them always produces the most useful outcomes.
Not because planning poker is inherently flawed, but because the conversations surrounding it can be.
The influence of a strong opinion
Experience is incredibly valuable in software development.
Senior engineers often recognise implementation patterns, understand architectural constraints and can identify potential problems before anyone else.
That's exactly the kind of knowledge we want in an estimation session.
But there's a subtle problem.
When someone with considerable experience expresses a strong opinion, that opinion can influence the rest of the team, even when other participants have legitimate concerns.
A less experienced developer might think an issue is more complicated but struggle to articulate why.
Someone else might have encountered a similar problem before and know about a dependency that hasn't been discussed.
Yet the conversation can gravitate towards the most confident explanation.
This isn't necessarily intentional. It's a natural consequence of people having different levels of experience, confidence and familiarity with the work.
The challenge is making sure we're evaluating the reasoning behind an estimate, rather than the authority of the person giving it.
Not everyone has the same context
Another problem I've noticed is how unevenly knowledge is distributed across a development team.
When an issue is introduced, some people already understand it.
Perhaps they helped define the requirements, worked on a related feature or know the area of the codebase particularly well.
Others are seeing it properly for the first time.
They might understand the general objective, but not the implementation details, existing dependencies or potential complications.
And that's perfectly normal.
We can't expect everyone to have the same knowledge of every part of a product.
The difficulty comes when we ask everyone to estimate the work as though they share the same understanding.
Some participants are estimating based on detailed knowledge.
Others are estimating based on a high-level description and a handful of assumptions.
We're asking everyone the same question, but we're not necessarily giving them the same information.
That difference matters.
The constant search for context
Then there's the practical reality of an estimation meeting.
Someone raises a question about the requirements.
We switch back to GitHub to read the issue.
Someone mentions a related pull request, so we open another tab.
Perhaps there's a dependency on another issue, or a previous implementation that might help explain the complexity.
We investigate, discuss what we've found, and eventually return to the planning poker application.
Then someone asks another question.
And off we go again.
The problem isn't that we're looking for information. That's exactly what we should be doing.
It's that the information is scattered across different places, and the estimation tool itself often contributes very little beyond allowing everyone to select a number.
The team is doing the hard work of understanding the issue somewhere else.
We don't have unlimited time to investigate
Ideally, we'd thoroughly investigate every issue before estimating it.
We'd examine the requirements, review the architecture, identify dependencies, consider testing scenarios and resolve every ambiguity.
But that's rarely practical.
Development teams have limited time for refinement and estimation.
There might be ten issues to discuss, several developers involved and other work waiting to be completed.
We need enough understanding to make a reasonable assessment, but we can't turn every estimation session into a detailed technical investigation.
So we make assumptions.
We rely on previous experience.
We use the information available and try to move the conversation forward.
Sometimes that works well.
Other times, important considerations only become apparent once development has started.
The question I became interested in was whether we could help teams uncover more useful information without significantly increasing the time spent estimating.
Why I built Pointwise
These frustrations led me to build Pointwise, a collaborative planning poker application integrated with GitHub Issues and GitHub Copilot.
I wanted to address four related problems:
- Opinion bias: Help participants form independent estimates before being influenced by others.
- Uneven understanding: Give the team additional perspectives on requirements, complexity and risks.
- Fragmented context: Keep GitHub Issues and estimation within the same workflow.
- Limited time: Make it easier to identify questions worth discussing without requiring a full technical investigation.
The aim isn't to remove uncertainty from software estimation. That would be a fairly ambitious claim.
It's to help teams make better use of the time they already spend discussing work.
Independent thinking before consensus
Pointwise uses hidden estimation to help reduce the influence of early opinions.
Participants select their scores independently, and the estimates remain hidden until the session leader reveals them.
That means the senior engineer's three doesn't immediately become everyone else's three.
When the scores are revealed, differences become the starting point for discussion.
If one participant selects a three and another selects an eight, the team can explore why.
Perhaps someone knows about an existing implementation that makes the work straightforward.
Perhaps someone else has identified a dependency or testing challenge.
Both perspectives deserve consideration.
The objective isn't to eliminate disagreement.
It's to make disagreement useful.
Giving the team more to work with
This is where GitHub Copilot comes into the picture.
Pointwise integrates with the GitHub Copilot SDK to review issues from different professional perspectives:
- Software Engineer
- UX Designer
- Product Owner
- QA Engineer
- Business Analyst
- Security Engineer
Each perspective examines the issue with different considerations in mind.
For example, a QA review might identify missing acceptance criteria, edge cases or testing requirements.
A Security Engineer review might raise questions about permissions, authentication or data handling.
A Product Owner review might highlight unclear requirements or assumptions about expected behaviour.
These reviews can give the team additional questions and considerations to discuss, particularly when some participants are less familiar with the issue.
The intention isn't for AI to tell everyone what the estimate should be.
And it certainly isn't to suggest that AI-generated feedback is automatically correct.
Copilot can misunderstand requirements, overlook important context or raise concerns that aren't relevant.
Its observations still need to be assessed by the people doing the work.
The value is in providing additional perspectives that help the team ask better questions, rather than treating AI as another authoritative voice in the room.
Keeping everything closer to the issue
I also wanted to reduce the amount of switching between applications.
Pointwise connects directly to GitHub, allowing teams to find and read issues during an estimation session.
Participants can review the issue, submit their estimates, reveal scores and request Copilot reviews within the same experience.
That doesn't mean every piece of information is suddenly available in one place.
Some questions will always require further investigation.
But it removes some of the friction involved in moving between GitHub and a separate estimation tool, while keeping the issue itself central to the discussion.
Making better use of limited time
For me, this is probably the most important part of the idea.
I don't expect Pointwise to replace proper refinement, technical investigation or conversations between developers.
And I don't think AI can reliably turn an incomplete issue into a fully understood piece of work.
What I'm interested in is whether it can help teams make better use of a limited estimation window.
If a review highlights a missing acceptance criterion, the team can discuss it.
If it raises a potential dependency, someone can confirm whether that dependency exists.
If it identifies uncertainty that can't be resolved during the session, the team can acknowledge that uncertainty rather than burying it inside a story point estimate.
Sometimes the most valuable outcome of an estimation session isn't agreeing that something is a five.
It's discovering that we don't yet know enough to estimate it confidently.
Building the application
From an engineering perspective, Pointwise has also been an interesting project to develop.
The frontend uses React and TypeScript, with backend APIs deployed on Vercel.
Supabase provides persistent storage, while Upstash Redis manages collaborative estimation session state.
I use Redis Lua scripts to handle important state transitions atomically, helping prevent simultaneous participant actions from creating inconsistent session states.
GitHub OAuth handles user authentication, while the GitHub App manages repository access.
The application also integrates with the GitHub Copilot SDK for issue reviews and Stripe for subscription management.
One of the more challenging architectural aspects was keeping authentication, repository permissions and subscription entitlements separate while ensuring they worked together consistently.
It's been a valuable exercise in building a complete SaaS product, but the technical decisions have ultimately been driven by the experience I wanted to create.
Better estimation starts with better understanding
There are already plenty of planning poker applications.
If all Pointwise did was let developers select cards and reveal numbers, I don't think it would be particularly interesting.
What I wanted to explore was whether we could improve the quality of the conversation around those numbers.
Reduce the influence of strong opinions.
Give people with less context a better starting point.
Make relevant information easier to access.
And use AI to surface questions that might otherwise be overlooked, without expecting it to make decisions for the team.
I don't have evidence yet that Pointwise produces more accurate estimates. That's something that would need to be evaluated through real team usage.
But I believe improving shared understanding is a worthwhile objective in its own right.
Because ultimately, the value of estimation isn't just the number we agree on.
It's what we learn about the work before we start building it.
I'd be interested in your experience
Pointwise is now available through the GitHub Marketplace, with a free plan for teams that want to try it.
I'm continuing to develop the application and would welcome feedback from teams that manage their work through GitHub Issues.
I'm particularly interested in how other developers experience estimation sessions.
Does everyone genuinely understand the work before voting? Do senior opinions sometimes influence the outcome? And how often do you find yourselves switching between applications just to gather enough context?
Are we using estimation to understand the work, or are we sometimes just trying to agree on a number?
Top comments (0)