Agile Points Estimation
I broke this down in the video above. Below is the written version, expanded into a fuller guide to agile estimation, planning poker, and the velocity it feeds.
Agile estimation is the hardest part of agile to get right, and most teams take several sprints before it clicks. If your estimates feel like guesses or your sprints keep overcommitting, this one is for you. On a scrum team you quickly learn that sizing work is a skill, not a formula, and it takes practice before the process feels comfortable. In the video I walked through how we estimate, the planning poker technique we use, and the reason it all matters, which is velocity. Here I want to lay out the mechanics and then connect them to the velocity number that makes estimation worth doing.
Estimate in points, not hours
Most teams now estimate in points rather than hours, because points size the work without pretending to predict exact time.
The first shift is away from hours. Most teams nowadays use points instead of hours, and we do the same. Points size a story by its overall effort and complexity rather than claiming to know how many hours it will take. That distinction matters, because hours invite false precision that the work rarely honors.
I explain the reasoning in the video. Estimation is genuinely hard, and it usually takes several sprints before a team feels comfortable with how the process works. What I learned is that the discomfort is normal. Points let a team agree on relative size quickly, which is far more useful than arguing over an hour count nobody can actually defend.
Use planning poker to reach one number
Planning poker gets the whole team to vote on each story and then agree on a single estimate.
We use a technique called poker, which is simply a set of cards with numbers on them. Once a story is in the backlog, each team member gets a vote and plays a card to size it. We run a three-week sprint, so our base scale is two, five, eight, and thirteen. Each person votes, and then the team as a whole has to agree on one number, so there is a single estimate per story.
That agreement step is the heart of it. The vote surfaces disagreement, and the discussion that follows is where the team aligns on what the story actually involves. The goal is one shared estimate, not an average, so the conversation continues until the team genuinely lands together.
Keep it high level and break down the big stories
Keep estimation discussions high level, and break down any story larger than your top card.
Estimation goes sideways when the team drops into design. We keep the discussion at a fairly high level and avoid getting into implementation detail, because that is what makes it hard to land a realistic estimate. The point is to size the work, not solve it.
The scale also acts as a filter. Because we run a three-week sprint, anything larger than thirteen points needs to be broken down into smaller pieces, since a story that big usually cannot be finished inside the sprint. One more rule keeps the numbers honest: the product owner and the scrum master do not vote. Only the team members doing the work provide estimates, because they are the ones who have to deliver.
Why it all feeds velocity
The real reason to estimate is velocity, the measure of how many points your team actually completes per sprint.
Estimation is not busywork. We do it to figure out, as a team, how much work we can take on in a sprint and what our velocity is going to be. I walk through velocity in the video. Velocity is simply your planned points versus your actual completed points, and the value comes from watching that trend across several sprints rather than reading any single number.
I found that velocity also makes future estimates easier. Once a team has three or four sprints behind it, you can look back at previous stories and use them as a guide for sizing new ones. A story that feels like that old five-pointer probably is one. That history turns estimation from a guess into a calibrated judgment, which is exactly the comfort that takes several sprints to build.
The takeaway
Agile estimation gets easier when you treat it as a skill that takes practice. Estimate in points rather than hours. Use planning poker so the whole team votes and agrees on one number per story. Keep the discussion high level and break down anything over thirteen. Let only the people doing the work estimate. And remember why you are doing it, to learn your velocity and use past sprints as a guide. Give it several sprints and the guesses turn into reliable judgment.
If this helped, the full walkthrough is in my video on agile estimation. Here is my question for the comments: what point scale does your team use, and how many sprints did it take to feel comfortable? Subscribe if you want more practical agile and DevOps guidance.
