6 min
Story Pointing wasn’t a completely novel idea. It evolved out of the Delphi method — a research technique that helped drive consensus and forecasting built on collective wisdom. In 1950s, RAND Corporation began using it as a way to forecast the effect of technology on warfare.
So, it wasn’t just an idea dreamed up by someone in the Agile community randomly — no. It’s actually based on a scientific approach. Something that’s been applied and true in other disciplines for many, many years.
And, when Scrum needed a prescriptive technique to help the Teams estimate and measure the amount of work the Team could consistently deliver Sprint after Sprint, this became a recommended approach.
Built on the concept of yesterday’s weather — “if we were able to complete X things yesterday, we’re likely to complete the same amount today”, Story Pointing made it very easy to count volume of work completed via velocity and use that to project future plans.
Today, however, we find lots of Teams being very frustrated and disappointed with the technique. We see velocity to be misused by the senior leadership and many Teams aborting Story Points in favor of other estimation and forecasting techniques or no techniques at all.
Which brings us to many good questions:
- Is Story Pointing still valid?
- Does it work?
- Or, should Teams consider to something else?
Does it Work?
Those of us who have been in software development during the late 90’s and 2000’s have seen Story Pointing work well. It was a huge improvement over the way people worked back then — practically a wild guess for a deadline made with an 8 Magic Ball. We experienced it first hand.
But… we’ve also seen many things that have been done wrong. When Story Points are not properly applied – they will never work.
Story Points will Never Work If:
Turns out, there is nothing wrong with the technique, but Agile is less about techniques and more about people. When it comes to Story Pointing, this is exactly where we fail.
#1. The Team has never established a solid Story Point baseline.
When we were starting out with Story Points, we met as a Team to come up with a solid baselined estimate for our work. We picked a Story we’ve done in the past that was relatively simple, but required touching every component in the system — database, backend, frontend, and user experience and we agreed that we would give this baseline 3 points. Any work more complex, will require a higher number. Any work simpler, a smaller number.
This was the first crucial step to reach alignment. I am surprised how many Teams attempt to estimate without even a slightest baseline. When numbers mean different things to different people — Story Points will never work! Even adding a new, even experienced person from another Team to your Team will need an understanding of the baseline. So first thing first, don’t miss this step!
#2. Voting in the Open
Story Poker is called “Poker” for a reason. People need to hide their numbers and reveal at the same time! Because without it, people turn to their human behaviors…
Do these sound familiar?
“Why do I need to listen, the Tech Lead will spit out his number and I’ll just say the same. Who cares…”
“I’ll just say the same thing everyone else says, no need to argue… when will this meeting be over anyways? Just hurry up already… “yeah, ok, a 5”
“Dude, it doesn’t matter what I say, these numbers have no actual measurements.”
People seem to always forget that Agile is little bit about structure, and a lot about people!
If you have a wrong team with members not willing to work in an Agile, proactive way, self improving way no amount of training or Story Pointing will improve the results.
Story Poker is not a place for engineers to bluff with Fibonacci!
#3. Overpowering
The Team starts throwing around numbers and the conversation goes like this:
Scrum Master: “So, how many Story Points do you think this task is?”
Developer: “At least 5.”
Product Owner: “Why 5?”
Developer: “Because it feels bigger than a 3, and I don’t want to be the one who says 13.”
Putting the pressure on Teammates to lower their numbers is a balancing act. Yes, teammates need to challenge each other’s assumptions, but don’t ridicule the vote. Its not the number that’s important, but the reasons behind it!
“Why is it 13?” — is the most valuable question in the scenario above. Followed up with, “what is it about this feature/requirement/task/work that makes you think its so much above our baseline? What do you see that everyone else missed???”
#4. Lack of Believers
Organizations joining people together calling them “Teams”, but they aren’t truly Teams. They are just groups of people executing work in the same area. To make Teams truly Teams they have to share the same goals, vision, and purpose!
Teams consisting of some engineers that just don’t want to establish common ground, rules, policies, and even belief system will not be able to follow any aspects of Agile discipline. Because Agile IS a discipline.
David Snowden said it best in one of his keynote speech — “we put people together and expect them to be teams, but true teams in the nature aren’t formed this way. They are formed with either recruitment of like-minded or joining by those of shared values, cultures, and beliefs”
This is one of the reasons why investing in Team Building used to be huge — because the ROI of aligning on the purpose to drive better results was there. The proof? Nothing breaks up a team more and makes it poor performing than hiring an “a**hole”.
#5. Grooming is Painful
When all a Team does is meet for a Timebox of 1 hour every 2 weeks to prioritize and story point the work, only to barely scratch the top of the backlog — its obvious things will fail. Rushed Teams will agree to anything. After all, software developers don’t love to talk. They love to code.
Hence, Teams need to be prepared for those meetings. Grooming session is not a Ground Hog day to learn what they’ll be decomposing and learning about for the first time.
Give them the information early — after every Sprint — what’s next? And not in backlog items, but in terms of strategy. What is our #1 Goal right now? What Goal is next? What bets we will be making to meet the Goal?
Give them everything they need to come prepared for Grooming:
- Is there a design document? Are there any diagrams?
- A Video team can watch? A customer survey? A User Experience mockup?
- Is there another Team that engineers need to talk to?
- And finally be ready to explain Why feature is important.
Grooming is not a presentation session, its an information gathering session. You’re inviting engineers and QA to speak and ask questions, not listen to instructions on what has already been decided.
#6. Velocity
Lot’s of companies use the Velocity metric wrong leading it to become a performance metric. It isn’t!
Velocity is an internal Team Metric. So are the Story Points. It’s for the Team to know, and for the Team’s eyes only to use.
Leadership just needs to know Sprint Goals. Goals met, or when they are expected to be met ( a calendar date ). That’s it.
As far as the Teams, once the amount of work that meets velocity is added to the Sprint, forget the points!
Don’t touch them, don’t change them, don’t count them!!!
Just do the work, based on the priority of work items. You’ll count Velocity once Sprint is done, and you’ll compare it against the previous Sprints to observe any notable changes.
Otherwise, the fixation on Velocity, the reporting by Velocity will make the entire Team focus on Velocity! I’d rather have Teams focus on great work!
Conclusion
Story Points aren’t broken. People are.
When teams align on a baseline, protect estimation from bias, and treat velocity as their metric (not leadership’s), Story Pointing still works. When they don’t – it fails.
Agile was never about the numbers; it’s about trust, conversation, and shared purpose. Get those right, and the results will follow.
Did you know that Story Poker is built right into Project Simple in a fun, gamified experience?
- Teams can estimate directly in context — no switching tools, no plugins, no lost notes
- Can be used in Sync or Async modes with team members voting during an online meeting or voting on their own on all the backlog items before the meetings to focus the time on quality discussions.
- Once Team agrees on final number, the estimate is automatically updated in the backlog item.
Reach out to us to learn more about how Project Simple connects estimation, planning, and delivery into one continuous flow — no spreadsheets, no guesswork.
