Stop Using Story Points

Posted October 12, 2012 by Joshua Kerievsky

Sprints, standups and story points have come to symbolize Agile methods much like burgers, fries and cola symbolize fast food.

Ready for your Agile Happy Meal?

I hope not.

Like researchers of fast food, we now know that the Agile Happy Meal contains unnatural ingredients that decrease agility and cause process indigestion.

In 2007, a series of experiments led my colleagues and me to increase our agility by dropping story points and velocity calculations.

Those same experiments led us to replace fixed-length sprints with a flow-based workflow, and move from standup meetings to frequent team huddles.

Our process today looks nothing like a by-the-book, mainstream Agile method largely because we actively look for process waste and experiment to discover better ways of working.

In this blog, I'll explain why we dropped story points and velocity calculations and what you can do to work successfully without them.

My Early Days with Story Points

I started using story points on an Extreme Programming team in a San Francisco startup in 1999.

I loved how story points helped identify a team's work capacity.

That capacity, calculated as velocity (number of story points completed per timebox), helped people on teams (especially product managers, product owners or internal customers) learn to work within their means.

If the work to be done in a timebox didn't add up to the team's velocity, it was time for some critical thinking and decision making about must-haves vs. nice-to-haves.

Story points and velocity helped teams save time by identifying essential functionality and removing anything unnecessary (or "maximizing the work not done", an often-repeated mantra).

I used story points and velocity for another 8 years, both on internal projects and on client projects around the globe.

During that time, I noticed many misunderstandings and misuses of story points and velocity calculations.

At first, I interpreted these problems as a sign that we needed to do a better job of educating people.

But as the years passed, it became clear that story points and velocity calculations contain deep flaws.

Irrational Story Point Inflation

One of first big problems I noticed happened in a large, famous corporation headquartered near Tampa, Florida.

We first got to know this company in 2002, when a Director (I'll call him Jim) came out to San Francisco to experience our intensive Extreme Programming Workshop.

Jim loved what he experienced and wanted to immediately bring it back to his teams in Florida.

We went on to have a 4.5 year relationship with hundreds of people within Jim's company, including 2 of the 3 major corporate divisions.

For the first team, Jim bought a complete agile transition package, including our readiness assessment, training and coaching services.

He took our advice and designed a fantastic open-space for the 25-person team (big by agile standards at the time).

He had his entire team study and discuss Patrick Lencioni's Five Dysfunctions of a Team prior to us working with them.

When we landed in warm, sunny Tampa, we met one of the best-prepared teams we had ever encountered.

Fast forward 2 years and this team had shipped a great deal of excellent software ahead of schedule, received healthy bonuses for their work and won the parent company's prestigious process improvement award.

Executives who visited the company would routinely tour this team's open workspace and learn about their process.

We were proud of this team and completely unprepared for what was about to happen to them.

One day in 2004 Jim exhorted the team to go faster.

He used the term "sprint" even though he wasn't familiar with Scrum.

This team had an average velocity around 52 points per iteration.

Their velocity would flunctuate by a few points, but generally remained steady.

Yet just weeks after Jim asked the team to "sprint", the team's velocity jumped up into the high 80s!

I asked someone what happened.

She looked at me funny and said "These days around here if you sneeze, you get a story point."

I shook my head, amazed at how a mature agile team, a team that had been assessed, trained and coached by myself and two excellent Industrial Logic coaches, could so suddenly inflate their story point estimates to appear like they were going faster.

My confidence in story points and velocity calculations began to erode after that experience.

Yet perhaps the problem had been due to insufficient education?

Rather than abandoning story points in 2004, my colleagues and I redoubled our efforts to better educate our clients, especially management, about the misuses of story points.

Sacrificing Quality For Predictability

Technical practices like test-driven development and refactoring are often the first things to be dropped when someone is trying to "make their estimate."

We see this behavior emerge from the outset, starting in training: a team that completes all work at the end of a timebox (say, two hours) often does so by sacrificing quality.

For years, we addressed this common problem by helping students experience what it was like to deliver on commitments while also producing quality code.

We explained how great teams ultimately learned to maintain technical excellence while also sustaining a consistent velocity (the same number of story points completed per sprint).

Yet the fact is, such teams are rare and their consistency is often fleeting as their team size changes or other pressures take hold.

For too many years, I thought it was important to maintain a consistent velocity, since it was supposed to be helpful in planning and predicting when a product/system could be completed.

Yet I've seen too many teams sacrifice quality and face compounding technical debt solely to make or exceed their estimates and keep their burndown charts looking pretty.

Comparing Teams By Points

Over the years I've heard several managers at different companies ask, "Why is team X getting 24 story points done per sprint, while team Y is only getting 12 story points done? Those teams are roughly the same size, so why the discrepancy?"

Instead of treating velocity as a team-specific, capacity indicator, such managers fall into the trap of thinking of velocity as a performance measurement (as Jim Highsmith described in Velocity Is Killing Agility!).

We can educate people to not compare teams by their velocities, yet it is a real problem that so many people naturally reason that such comparisons are legitimate.

Starting around 2005, I tried to deal with this problem by having teams name their story points after favorite types of fruit.

One team woud measure velocity in oranges, another would measure it in apples, another in kiwis, etc.

Then, when management invariably tried to compare the velocities of teams, I would tell them that "You can't compare apples to oranges."

While this approach helped to point out the fruitlessness (pun intended) of comparing team velocities, it led me on a path of doing more and more work to stop people from misusing story points rather than shift to a simpler and less error-prone method.

Story Point Confusion: Are We NUTs?

Many justify the use of story points because they say that humans aren't good at estimating using actual time.

They say that story points make us better at estimating because we're estimating the size of work, rather than the time it takes to complete it.

In fact, humans aren't very good at estimating in general, regardless of what measure is used.

As I will show later, teams get better estimates when they re-estimate frequently.

Story points just further muddle the issue.

While we grow up estimating using time (e.g. "When will you be ready to go?" or "How long before you arrive home?"), the same cannot be said of story points.

To use them, we must learn:

  • what they are,
  • how to use them,
  • the many ways to not misuse them.

A typical education in story points contains a good deal of friction.

Newbies are confused and uncomfortable estimating with story points and frequently compensate by consistently translating story points back to actual time estimates.

Well-meaning agile experts do their best to educate the uninitiated.

They explain how story points are like t-shirts sizes or Fibonacci sequences.

In 2005, one of our customers found story points to be so confusing that he renamed them NUTs (Nebulous Units of Time).

Misunderstandings and misuses of story points generally multiply over time, especially as a process scales from team to department to enterprise.

Fixing those misunderstandings and misuses costs time and energy.

Story points and velocity calculations are unnatural techniques that unnecessarily confuse teams at the beginning of their agile journey.

Busy-Ness Accounting

I visited a company the other day that had giant kanban boards filled with technical tasks in various stages of completion.

I couldn't tell from these physical boards if the teams were working on valuable user stories.

I couldn't see progress on release plans and looking at their web-based Agile planning tool didn't provide much help either.

Instead, the tool was ready to show me pretty velocity charts and report on how many hours tasks took to complete.

So many Agile shops seem to be stuck in this mode of tracking busy work.

My colleague Tim Ottinger calls it "busy-ness accounting."

Breaking down a user story into tasks is fine to understand what will be involved in completing it, but spending loads of time estimating tasks and tracking the tasks on agile planning boards/tools is a lot of wasted energy and a relic of waterfall-based planning schemes.

Being agile means moving with quick, easy grace.

That means releasing useful, quality software frequently.

It doesn't mean being busy accounting for how every hour is spent doing technical tasks.

A Simpler Way

In 2001, I remember being struck by a simple planning approach mentioned by Don Wells, an early Extreme Programmer who worked on the Chrysler Comprehensive Compensation System project (the birthplace of XP).

Don said (in this email from the Extreme Programming email list):

We have been counting items done. Each week we just choose the most important items and sign up for them up to the number from last week. It turns out that we get about the same number of them done regardless of estimated effort. We have 1 week iterations so we tend to break things down a bit at the iteration planning meeting.

Perhaps the effect is that we have learned how to break things down to the right size. I don't know yet, but the point is we get about 8 things done each week, no estimation required.

While I wasn't ready at the time to try Don's simple planning approach, he had whet my appetite for a simpler planning formula.

Experimenting With Alternatives

By the Spring of 2007, my colleagues and I had seen enough problems associated with story points and velocity calculations that we began experimenting with simpler solutions.

Our first experiment within Industrial Logic failed badly.

We tracked real-time hours instead of story points, but we were essentially doing the same thing with hours as we had done with story points: carefully accounting for estimated hours, completed hours and a new budget of hours available for the next fixed-length timebox.

This project lasted approximately 6 months and afterwards, more than half of the people on the project said they disliked using real-time estimates with hours.

That Summer I attended the Agile2007 conference in Washington, DC and heard David Anderson speak about his Kanban method during an open space, birds-of-a-feather session.

I loved what David had described and it inspired me to continue searching for a process that better fit my company's needs and culture.

In the Fall of 2007, we stopped using story points or hours and started working in what I called (at the time) "variable length iterations."

No longer happy to work in fixed-length timeboxes, we would simply pick a small amount of important work to do, complete that work, ship it and repeat.

In general, we didn't care if it took 1 day or 4 days to get the work done.

Our focus was on shipping, not working in a fixed timebox or tracking the number of story points completed.

Using the new process, we shipped (on average) 1-2 times per week.

Our agility had increased by removing once-sacred pieces from our process.

We were now even better at delivering on the promise of the Agile Manifesto's first principle:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

If we had a deadline, we would make it by either getting everything done or finding work that could be safely deferred until a later release

Our planning sessions were much shorter and we judged ourselves on whether we had shipped valuable software, not whether we had maintained a consistent velocity.

I learned that what I had called "variable-length iterations" was actually more like a flow-based workflow in lean development.

And in lean terms, I started describing story points as waste, like the empty calories in cola.

Gut Feel

In 2008, Industrial Logic was asked by a Silicon Valley startup (now owned by I.B.M.) to help one team inside their company become agile.

One of our coaches worked with that team for several weeks, teaching and coaching them in traditional agile practices, including the use of story points.

At the time, we were not yet comfortable teaching our story point-free approach to our customers.

A few months after this first project completed, the company asked if we could now help them spread agile across the whole company.

We worked out a transition plan which included having me interview the first team that had already gone through the process change.

When I walked into that team's open workspace, I saw the walls covered with posters showing burn-down charts, release plans, iteration plans and charts tracking the team's velocity over time.

I sat down with a woman who had a reputation for being the company's best product manager.

After a few minutes of talking, I pointed to some of the posters on the walls and asked how things were going with planning and estimation.

For a brief moment she looked at me funny.

Then she said that everything was just fine, that they were tracking velocity with story points and using their velocity to schedule just the right amount of work for their iterations and releases.

Something about her expression suggested that something was amiss.

"Are you sure?" I asked.

She paused for several seconds, then said, "Do you want to know the real answer?"

I said yes.

She then said "You see those posters with the velocity numbers? We made all of those up because we knew you were coming to visit us and we wanted you to say nice things about us to our management."

"Really?!?", I said, rather surprised. "So what do you actually do?"

She explained that she and her team simply used gut feel to choose the right amount of work for a 2 week iteration or 2 month release.

If they needed to adjust the plan, they did so, always keeping stakeholders informed.

She said that this gut feel approach to estimation and planning had been working just fine and that they had no need for story points or velocity calculations.

I complimented her on the simplicity of her approach and assured her that what she was doing was perfectly agile, that using story points wasn't necessary to be agile.

And then I explained how Industrial Logic had stopped using story points for our own product development a year earlier.

Periodic Release Planning

Many of us estimate in order to know when we can release software to our users and what it will roughly cost.

At the beginning of a project, most release plans and dates are a nice fantasy.

You could spend days or weeks attempting to get more accurate estimates, yet I find it is better to just make rough estimates for each user story based on 10-15 minutes of analysis and discussion per story.

To get higher value for less cost, I coach teams to do Bargain Hunting.

To get more accurate estimates, I coach teams to periodically (say, every 2 weeks) re-estimate the user stories on their release plans.

As time marches on, teams that regularly re-estimate their release plans get faster at it and provide time-based estimates that become increasingly accurate as the release date approaches.

That gives management what they needed all along: a decent way to predict the scope, schedule and cost of a release.

With this approach, there is no gaming of velocity numbers and the focus repeatedly returns to scoping discussions and what will/won't be released.

I coach teams to write user stories for their releases and estimate them using "team weeks": the amount of time it will take the whole team to complete the work.

It doesn't matter if only 2 people on a team of 10 can do the work: just provide the estimate as either .5, 1, 1.5 or 2 team weeks

If the estimate for a user story exceeds 2 team weeks, I ask the team to split the story so that it can be estimated at or below 2 team weeks.

To better manage risk, it's useful to combine evolutionary design with release planning.

Your first embryonic version of the product/system should include high value features and address your highest risks.

That release (which could take 1-3 months to produce) may be an internal milestone rather than something released to customers.

The next release will add further sophistication to the emerging software by adding functionality to existing features or producing new features.

And so it continues until you are ready to release to your customers.

All along the way, a team must make sure that the number of estimated team weeks on their release plan fits with the number of calendar weeks left for the release.

If there is a discrepancy, it's time to re-scope, re-think and re-plan the release so it fits with the team's work capacity.

I've found that this style of planning is simpler and yields better results than estimating with story points and feeling bad that you didn't hit your estimated velocity for a given sprint.

Periodic release planning helps people manage risk by repeatedly focusing on what valuable functionality can be delivered.

What's the Point of Story Points?

Story points and velocity calculations are now seen as defacto parts of Agile, legitimized by popular books, embedded in planning tools, verified in certifications and widely practiced in the industry.

Yet nearly all of the veteran agile practitioners I know haven't used story points or velocity calculations in years.

In the early days of Agile we thought there was a point to story points.

Yet we were careful to not let our ideas and practices ossify: to become set in a rigidly conventional pattern.

Today, we have simpler, less defective agile estimation and planning approaches.

Some now do what Don Wells once recommended in 2001: to work on the same number of similarly-sized stories each sprint.

Others work without sprints in a flow-based model that includes periodic release planning.

While there will never be one right way to be agile about estimation and planning, you would do well to avoid yesterday's outmoded and highly defective techniques.

Or in other words, be careful of what's inside your Agile Happy Meal.

  • J. B. Rainsberger

    Thanks for this, Josh. I wonder: do you think you’d feel as comfortable working without iterations and story points if you hadn’t spent several years working with iterations and story points? I remember in 2000 and 2001 reading things like, “I feel like we’re going to abandon iterations soon, as they’re getting in the way of releasing stuff,” and realised that some people mind outgrow iterations, but at the same time, I still think iterations can focus (at least) a team’s energy on actually delivering something every week in a way that they simply didn’t do before.

    I agree with you about this, though: story point estimates sometime help teams identify when they have strong disagreements about the amount of work that a story represents, but once they agree on those things, I think they can throw the points away and never use them again. As a tracking tool, it simply creates many many more problems than it solves, on average.

    Thanks again.

    • Tim Ottinger

      I don’t doubt that a lot of the practices agile teams adopt are really training wheels. That’s how I see sprints and story points in general. But without those, they often won’t learn to balance and move (TDD, Pair Program, etc).

      I was thrilled to see Josh write this.

    • Jez Humble

      In general I think estimation is a hugely misleading exercise that has some useful byproducts, in particular creating a shared understanding of what it is we’re going to be doing as a team, and where the dragons are. I think that’s true whether done at the iteration or release level. We need to be able to get to the same result without the attending baggage of a bunch of guesses which we can be certain will be wrong, but which are used to feed the cost accounting beast that drives so many of the bad organizational behaviours we see.

      At the iteration level, why not just ask – at the point of prioritizing some piece of work – if it’s going to take more than a few days? If so, it’s too big, and we need to break it into some smaller pieces that are still useful and valuable in their own right.

    • Joshua Kerievsky

      I’ve been experimenting with having newbies work in small, but not fixed, timeboxes and focusing them on evolutionary design with good technical quality. It seems to be working nicely, as it avoids the dysfunction that comes with the hurry-up-and-finish-before-end-of-timebox problem. I think that iteration/sprints and story points aren’t training wheels, they are just legacy parts of the agile movement. I hope to write more about this, as it seems that many think that anything other than traditional agile is *advanced* and that is just not the case at all. In fact, I’d say that sprint/iterations and story points are advanced, since only people with a great deal of experience can use them without all of the typical problems.

      • Curtis Cooley

        Wow, this is spot on. Just like we teach continuous improvement to the teams we coach, if we don’t apply the same principle to Agile it will stagnate and fail. In the beginning, iterations, story points, and estimation seemed like good things taken from high ceremony processes but applied in agile ways. Applying continuous improvement to Agile led us to betters ways of delivering valuable software early and often..

  • Jon Kern

    Especially for relatively fixed teams working inside of a corporation to deliver a product… to spend lots of times in a ceremony derived at yielding estimates that are a lot like a Gantt chart seems wasteful. Just keep the right set of prioritized features in front of the team, trust that they will bang through them as fast as they can with good quality, and drop the ceremonial estimates. It’s a T&M project, not fixed price.

  • James Ladd

    There is a big difference between estimation/prediction and accounting/review. When story points are used for both that is when a problem occurs.
    Big fan that you ditched something in the Agile book for something that works for your team. You might say you were *cough* agile.
    – James.

  • scotty7

    More like “Stop abusing Story Points”.

    #1 “Irrational Story Point Inflation” is a no-go and would end up on my impediment list.
    #2 “Sacrificing Quality For Predictability” is a matter of technical debt, with one may live with.
    #3 “Comparing Teams By Points” is also a no-go. Yes, sometimes you got to be snappy with management.
    #4 “Story Point Confusion” no one said it would be easy. Like in #1 the team need to stay disciplined.
    #5 “Busy-Ness Accounting” now that’s true, i should do that less and focus on useful release planning.

    Disclaimer: My agile developments have been my own initiative for about an year. I’m also a team leader since about then, but currently we are working on a “Big Project”. That project is driven by Scrum, but i am not the Scrum master. So some of the following practices my make you think “why don’t you do something about it”.

    Now let me explain how Story Points work for my team and me.

    An Epic spans Stories to reach a goal. A Story is at least one Ticket in our Ticket System. A Story is also one Card on the Kanban Board. An Story consists of Tasks. A Task is something you’d write on a Check list. An Task equals a Story Point.

    In “A Simpler Way” Don just counts the Number of Stories Done. I found that imprecise. For example if we’d plan 9, is it way to much? Or 7 way to low? Multiple Points to a Story however smooth-en the estimation. Just add or remove Stories to balance out. I like to keep my balance 10% above average. Not completing all Points in a Sprint is not a fail after all if the Goal (Epic) is met.

    We also are “Experimenting With Alternatives”. Currently everyone got (the order) to estimate in hours.
    To my dislike everyone is comfortable with that, but not committed Oh no! The hours are about 50% off but still plans get stuffed, even overstuffed to the actual working hours. I certainly want to get rid of this practice.

    Without time boxes points do not become pointless. When in Kanban mode we release as we please. Now you may track how many Points have been Done/Deployed in the last week on a daily basis. Besides Cycle Time and Disneyland Wait Time you can estimate release of an urgent story by points.

    I think our ill-fitted hours estimation works because it’s basically a “Gut Feel” estimation BUT ALSO a gut retrospection. When we totally overstuffed the last Sprint, there was a common gut feeling that still everything was A-OK with it. Didn’t seem so good to me, but the Velocity in Points still looked well.

    The last chapters just describe what we all know. Agile isn’t just for the team. Overall plans need to be re-evaluated constantly. There is no use in a team that’s trying to be agile while the management plans in waterfalls and endless scopes.

    I couldn’t draw a single lesson from your article, still your advice is welcome.

  • Jesse

    Great post. We do team week sizing on a continuous pull backlog across a dozen agile teams and have all the forecasting we need.

  • Yuval Yeret

    Great article. I too have been experimenting with avoiding story points and especially avoiding sprint commitments ( which is where story points start to head south IME), using scrumBan style of iterations or just kanban flow. ( see for some earlier thoughts)
    Something I’ve been experimenting with is planning releases using epic/feature stories where the team estimates the number of stories the bigger release-level story will be broken down to ( eg 20 means we expect something around 20 stories eventually). This is what sits on the release backlog. It provides release planning but keeps the iteration level flow simpler. Of course some stories will still be bigger than others and there is a challenge how to deal with that. But if the occurrence of those stories over time is predictable then we don’t care.

    Btw This article convinces me even more that scrumBan/kanban is simpler than Scrum to do right and raises the question whether that is part of the reason some people don’t like that very much…

  • Yuval Yeret

    One thing I’m not sure I got is the team-weeks aspect. So if a story is something just 2 out of 10 members in the team will need a week to deliver, is that a team-week? 0.5 team-week?
    Seems like too many small unswarmable stories will taint the picture, but maybe I’m getting it wrong.
    Thanks, yuval

    • Joshua Kerievsky

      Hi Yuval,

      Small stories help us deliver on our release stories. Every few days we complete small stories that begin as embryonic versions of our release stories. After completing a small story, we’ll work on a new small story that helps us continue to evolve the full functionality of the release story. Eventually, we’ve completed enough small stories to have the release story done.

      For a typical 3- to 6-month project, we don’t like to see anything smaller than a .5 team week story on the release plan. That means that small defects or small stories don’t go on the release plans

      If we have a release plan for a new system but get interrupted to fix a bunch of defects from an older system, it just impacts how much work we can complete for the new system, and the estimates for that release need to reflect our capacity. So we don’t tend to put bug fixes on the release plan, unless they are big and require at least a .5 team week to fix.

      Did that help clarify it?

  • Serge Beaumont

    I agree with the content of your points, not with the broad brush you use to have them apply to the whole agile community. I am an agile consultant, and in my work it’s more a function of a team’s or organizational agile experience whether they adopt something or not. Like you say: all of the VETERAN agile practitioners…

    Story points are really useful to get starting teams going, so they’re definitely training wheels. But forcing every team to ditch them? No way, that’s up to them. Some teams love them, others don’t. My role is to explain them the effects of their choices, not to decide for them. So I have teams that use story points and estimate tasks in hours, I have teams that use story points but simply count the number if tasks, I have teams that don’t use tasks, and so on. It’s all fine. Whatever works for them. And above all, *whenever* it works for them. Use Story Points, then switch to counting, back to Story points, why not?
    Story points are a perfectly okay tool in the agile toolbox, to be used, or not. Saying “no one should use story points” is just as bad as “everyone should use story points”. Absolutes are fine for sissies who don’t want to think for themselves, and for eliciting reactions to blog posts. I’ll continue using them if you don’t mind… :-)

    • Joshua Kerievsky

      Hi Serge,

      I’m not content with the defects inherent in story points, as described in the blog. I do not believe that story points are good training wheels or that newbies should start with them because they were part of the way we used to do agile planning.

      If you let go of the past and begin exploring simpler ways of working, you can find perfectly good ways to help newbies adopt agile estimation and planning without the process indigestion of story points and velocity calculations.

  • Richard Mouser

    Amazing job on this article, thanks for making the case against Story Points and Velocity, and providing interesting alternatives.

    Your “variable length iterations” are my favorite alternative to the current “norm.” Seems it would combine well with TDD, Continuous Integration and continuous deployment for a very streamlined process to evolve software.

  • Peter Saddington

    This article is legit, and I get it. As a coach for highly-regulated environments and big contracts (think DoD, Govt), can you give us a couple of examples of how you’d ‘estimate’ work for a large govt contract from your model? Or is it specific to high-tech?

  • Uncle Bob Martin

    Those of us who have coached agile teams are familiar with the issues that Josh raises. Many teams _do_ struggle with story points. I have certainly seen teams devalue those points when their project managers try to get something for nothing by asking the team to go faster. I’ve also seen teams fake their velocity charts for the benefit of project managers who were more interested in form over function. For such teams, a different approach may be warranted. However, I have also seen teams use story points consistently and effectively. I would not advise such teams to abandon the approach.

    One variation of the story point method that I’ve seen work particularly well is the 8th Light model. In that model the team is paid based on the number of story points they complete. This completely eliminates the incentive to get something for nothing by encouraging the team to “go faster”. Instead, both the business and the team agree on a cost for the stories. If the team rushes in an attempt to get more money per sprint, they know they’ll be making a lot less money soon as the mess grows. If the business thinks a feature is to expensive, they can negotiate it by cutting scope.

    Other, more traditional, teams have done well with story points. Over the years it has proven to be a relatively simple and effective way to introduce agile to customers. But Josh is right that there are many who struggle with various kinds of dysfunction. For them, a different approach is warranted.

    There is no reason to consider the story point scheme to be the default agile technique. Given the growing toolkit of agile ideas, a team (with the advice of an experienced coach) can pick from quite a selection. But I would not remove story points from the toolkit. There are many teams who will find it useful.

    New ideas are good, and we should embrace them. But all too often we see new ideas as replacements that invalidate the older ideas. This is seldom the case. We want to _grow_ a seasoned toolkit, not just keep the shiny new tools.

    • Joshua Kerievsky

      Bob, this blog has nothing to do with shiny new tools or discouraging people to use techniques that actually work for a majority of people. Too many people and teams fail with story points. We need to acknowledge that and move on. I completely disagree when you say that story points are “a relatively simple and effective way to introduce agile to customers.” In fact, they are a great way to produce agile dysfunction early on. We cannot be afraid to let go of older ideas and techniques that have failed a majority of people. There are certainly exceptions, yet the vast number of teams I meet or other practitioners I talk to all agree that story points get in the way of genuine agility. We can do better.

      • Jeff Potter

        How relatively simple is relatively simple on a scale of 1-5? :) If you know that answer you can use story points. :) People need to get back to the basics of the agile manifesto. Please read and repeat

        • Joshua Kerievsky

          Healthy movements get rid of things that don’t work well. Getting back to the basic of agile means having the courage to drop practices and tools that are malfunctioning repeatedly for the majority.

  • Kevin Peel

    The amount of cards that fitted into an arbitrarily drawn box on a whiteboard has worked well for me, at least once. A nice blog, perhaps the blog wasn’t as arbitrary as I thought and we didn’t just get lucky. Food for thought – thanks

  • BusinessCraftsmanship

    Glad to hear others are decrying story points and velocity as essential tools. They aren’t. I haven’t used story points in practice for many years, but I still teach the principle of relative sizing in workshops as it is a useful tool for essential dialog. In order to get all stories to a like-size there is certainly some “estimation” that needs to happen, but it need not concern points, or any other kind of number. There is value to using exercises like “silent shuffle” to size large batches of stories as it quickly surfaces those we need further discussion on, and those that need to be broken down further, or slimmed.

    Velocity may still be helpful to the business, but it’s based on business value items delivered, not some arbitrary effort number. Customers don’t care how long it took or how hard we worked. They care about the end result, as they should.

    I’m not in favor of variable length iterations though, as I believe rhythm is an essential part of being agile. Periodic, regular reflection is essential for improvement, and in order to ensure the right people are involved in these dialogs it is usually necessary to calendar them in advance. Whether a fixed-timebox-commitment-based model is used, or a continuous flow one, it is important to stop work on a regular basis to assess the work we’ve done, and the methods we use. The flow model need not be inconsistent with rhythm.
    Thanks for the post.

  • Rich Stone

    Great post. I completely get the pressures that management can apply that will cause a team to abandon valuable practices, or twist them so that they become less valuable.

    At the same time, story points are good and valuable because they make the estimates abstract, and consistent. They are also less valuable to management who wants to “cost” something, or project the impact of resource changes.

    Not only are story points not fungible between teams, they are not fungible between instances of the same team (as players come and go).

    I appreciate the careful treatment you provided the issue.

  • Emile Bakker

    Great article! However, I believe you miss out on the story point completly.
    Don’t kill the Story point. Not because I want an estimation.. But because I need at a certain point to have the team sit together to discuss the story. The tangible result of the meeting is storypoints.. but the real result is synchronization of the team on a story and the confirmation for the product owner that the story is really understood. As a product owner you should always be at this meeting.
    So, Storypoints is the instrument, but the actual goal is communication.

    • Stephan

      it’s never a good idea to make a mean a goal. Focus on the goal, not the mean.

    • Joshua Kerievsky

      Hi Emile, I agree that collaboration and discussion around stories is essential. Yet somehow people have come to believe that you can’t have productive collaboration and discussion without story points. You can. Story points aren’t at all necessary to productive exploration of user stories. One technique I like is called Bargain Hunting (there is a link to it in this blog). Teams that bargain hunt user stories find ways to get more done faster with far less work. Bargain hunting gets at the heart of the kind of collaboration and discussion needed to understand. It is best done by a Project Community, not a PO and some developers (see my blog called Community, Not Product Owner).

  • Don Wells

    Thank you for the shout out. I have come to realize something about Agile processes:

    The most important thing to know about Agile methods or processes is that there is no such thing. There are only Agile teams. The processes we describe as Agile are environments for a team to learn how to be Agile. (excerpt from

    In the context of learning, Story Points are still useful. They also provide an interface adaptor to management until management becomes Agile too. I am currently observing an Agile transition at Ford Motor Co. Oh the humanity…

    • newz2000

      One of the principles of the agile manifesto is that people are more important than processes. That does not mean there are no processes, but instead you pick processes that work best with your people. Some teams love story points, some hate them. I think a better headline is “you don’t have to use story points, here’s what we did” [edit: reworded last part slightly]

      • Joshua Kerievsky

        Perhaps you are reading into the blog rather than actually reading the blog? The 2nd to last line says “While there will never be one right way to be agile about estimation and planning, you would do well to avoid yesterday’s outmoded and highly defective techniques.”

        There are books, tools, certifications and speakers who continue to push story points. This blog is my way of countering that energy with hard-won wisdom from the trenches: story points are a highly defective agile planning technique.

        • Guest

          I’ll be honest, I couldn’t make it that far into the post, but as I stated in the comment, my gripe was with the headline, which I feel is a bit sensationalist.

        • Don Wells

          Absolutly, there are defects in story points. Unfortunatly story points make a lot of sense to a lot of people. That is hard to push against. I personally don’t like story points either. In fact I personally don’t like this whole idea of estimation because it is invariably wrong. But I know many organizations want them, lots of them.
          The last company I was with we didn’t do any estimation at all. We worked on the most important thing next. What we found is that when you do that and you have clear priorities, you can deliver software slightly before it is needed. If you keep quality high no one notices the software, that is, the software begins to be taken for granted. Need some new functionality? Who cares? It will just magically show up in production when we need it and work flawlessly.
          To get there you really have to be disciplined in all the other processes. When you let go of estimates and schedules you must replace them with a process that keeps ahead of need. You have to be able to negotiate scope honestly to get exactly what is needed at each release. You have to be very careful about quality, test coverage, and simplicity just to name a few.
          I agree with Joshua that story points should not be used, in fact, I think estimations are part of an obsolecent way to create software. It always goes off the rails.
          “How wide is my table? I look at my table and see it is about 6 feet wide. I then triple that to 18 feet wide so I don’t underestimate. But I know this room is only 14 feet wide. So my final estimate is 14 feet wide.” (excerpt from This is also how most software is estimated. Why go through the estimation process if we already know the final answer?
          More often than not we have a very good idea how much the business is willing to spend on software. If we have done our homework we know there is value in creating the software with sufficient return on the investment. If we are Agile we always deliver the most value for money invested to date. What else do you need to know?

          • Joshua Kerievsky

            Hi Don, yes totally agreed on no estimates and continuous deployment. We’ve actually been doing continuous deployment (if it passes the tests, it ships) for a few years now and we love it. We focus on high value work and ship constantly (many times a day). We ship small improvements that way and we evolve larger improvements that way (sometimes hiding new features until they are ready to be made public). It has simplified so much. And yes, we can do it because we have a ton of automated tests, courtesy of TDD.

            I’ve written about this on our blog – search for Continuous Delivery/Deployment (somehow when I post links here, DISQUS doesn’t show my entire comment).

    • Joshua Kerievsky

      Thanks for the comment Don. I believe we can do better than subject newbies and management to story points in the context of learning. I’ll write more about that one day.

      • Richard Mouser

        Joshua, please write that sooner rather than later. Great, thought-provoking subject.

  • Kim B

    The thoughts about making people aware of the pitfalls of points and educating people, so that they do not get abused, are great. Reminded me of learning to scuba dive. We spent the first few lessons learning about the many ways we could injure ourselves before we even got wet. Very much needed for diving, uncertain of the value for software delivery.

  • Mike Pearce

    “To get more accurate estimates, I coach teams to periodically (say, every 2 weeks) re-estimate the user stories on their release plans.”

    What do you estimate the stories on the release plan with?

    • BusinessCraftsmanship

      “Team weeks” seems to be the measure mentioned (read on past the piece you quoted). It’s a good measure. I prefer Team Days though, as being a little more granular. I like small stories.

  • Alexander Fürstenau

    Hi Joshua,

    interesting article but I am not sure if a different estimating unit makes such a big difference. As some of the former commentators pointed out. The result is not important but to be sure that the team understands the story well enough is.

    If a team doesn’t feel confident with story points it might be a good idea to try something else.
    As always inspect and adapt.

  • Troy Tuttle

    Very nice post. I love when community leaders challenge the prevailing thought and practices.

    I would just add one clarification. You might be painting with a broad brush in regard to Story Points. The term means a lot of different things to different teams. I agree that Story Points used for velocity tracking is not that helpful. It sends the wrong signal to teams and the organization.

    Story points used for basic relative estimating can be a very healthy thing, if they help a team express that the next feature is “about twice as large as the last few features”.

    I think you get to this indirectly with your “Gut Feel” section.


  • Farid Askari

    The reasons why we shouldn’t stop using Story Points and velocity:
    I don’t believe you could walk into any company in today’s business world and find any CEO or CFO who is not going to want some form of predictability of how much faster can he/she stay ahead of competition. The reason we do estimation is we want to make predictions. For the same reason we want to know the time it takes to fly the distance (backlog in story points) in miles from San Francisco to Chicago on a 727 Jet with some velocity (250 m/hr) is the same reason we want to know when we will get to a software delivery date. To arrive at some reasonable estimate of time (schedule) we need to use the backlog size (story point) and divide by velocity. By tracking or sampling velocity at discrete intervals (time-boxed sprints) and velocity variation’s (average, fastest, slowest) we can determine a time range for delivering the backlog. The other reason for predicting time is that in agile/lean we are trying to maximize the value/time, ie, we want to deliver value (without compromising quality) in the shortest amount of time, ie, shortest time to market, In lean, the shortest time through the system by minimizing waste and work in progress.
    Farid Askari

    • Neil Killick

      Predictability does not come from estimating – far from it. If any semblance of short term predictability can be gained It comes from empirical data (experience), not guesses of scope and of how long that scope will take to build. Yes, you want to know how long your flight to Chicago will take, and the airline will tell you but not because they have guessed how long it will take – it is because they have flown that route before so have a very good idea how long it will take. Further, the variables involved in predicting how long an airplane flight will take are far fewer than how long it will take to build software (an unpredictable creative pursuit) to meet a particular need.

      As to your second point about determining a “time range for delivering the backlog” – this is nothing to do with Agile or Lean. Scrum, for example, is about delivering the best possible product by a given date – i.e. the date is not estimated, it is fixed and we deliver the highest possible value on that date by continually prioritising the most important work and getting constant feedback. The shortest time to market does not have to be determined by estimation. It can be determined by a real world constraint such as time (we need something out in one month to beat our competitor to market) or budget (we’ve got $100k to spend, what can we do with it?) These constraints provide certainty that estimating a backlog (which, by the way, requires defining a solution up front, which doesn’t sound particularly Agile to me) does not provide.

      Estimation and contracts are not forbidden fruit. They are not untouchable as things we can improve about delivering software more effectively. Let’s start thinking about ways we can deliver value without having to estimate. Aside from being risky, time spent estimating or trying to get better at estimating is time away from building valuable software and delivering outcomes for our customers.

  • farid askari

    The reasons why not to stop using velocity and story points:

    I don’t believe you could walk into any company in today’s
    software world and find any CEO or CFO who is not going to want some form of
    predictability, such as the time to market for a product. The
    reason we do estimation is that we want to make predictions. For the same reason a business person wants to know (for planning) the time it takes to fly the distance (backlog in story points) in
    miles from San Francisco to Chicago on a 727 Jet with some velocity (250 m/hr) , is the same reason the management wants to know when we will get to a software delivery
    date. To arrive at some reasonable estimate of time (schedule) we need to use
    the backlog size (story point) and divide by velocity. The is the most practical method to get there, besides being a good education tool. By tracking or sampling
    velocity at discrete intervals (time-boxed sprints) and velocity variation’s
    (average, fastest, slowest) we can determine a time range for delivering the
    backlog. Also inspecting and adapting at discreet intervals (end of a sprint) is a good idea for continuous improvement. The other reason for wanting to predict time is that in agile/lean development we are
    trying to maximize the quantity value/time. The ratio is maximized when time gets small. We want to deliver value (without
    compromising quality) in the shortest amount of time. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” In lean processes, we want to strive at shortening the delivery time through the system by minimizing waste and
    work in progress.

  • Gabrielle Benefield

    In 2003, we looked at the metrics, and built for value – we used team weeks for rough predictions on timing. We didn’t use points at all and did lean/xp/scrum – Our revenue curve became a vertical cliff upwards. I’m with Josh on this one. We never missed it and although I don’t stop people using velocity as a throughput measure, it’s secondary indicator, not the primary one.

  • Gabrielle Benefield

    Cadence is good for creating feedback cycles on your products. Artificial containers for constraining natural work rhythms can be dangerous however. Although an iteration shouldn’t trigger when a product is released, it can create hard stops where the work is fragmented to fit the container and can lead to ‘frankenbuilds’. I hope the next plane I get on wasn’t built that way. Even Jeff Sutherland has the Type C Scrum which is all about pull methods and they used the cadence of feedback with no iterations. My most successful team had very small batch sizes, we tracked value created, stories completed and we had some flexibility on pulling new work in as needed. It was in early 2000 so we weren’t punished for not following the manual. Lucky us.

    • Stephan

      I think you are right; “Cadence is good for creating feedback cycles on your products.” – you need a regular feedback cycle. It is not necessary that the work is done in exactly the same rhythm. Sometimes you could deliver more value if you add a few days to the sprint or remove them.

  • tusjain

    You are perfectly correct that each team measure velocity with different fruit but trend in velocity may be a good measure and comparison of trends across teams will produce better picture. But with high level of attrition (especially in case of offshored projects) this comparison breaks.

    Apart from comparison of velocity, one should consider what has gone inside while giving story point to a story ( )

  • Paul Jackson

    A great article Joshua – you’ve articulated very clearly something that a lot of agile teams are facing. We came to a similar conclusion here at On the Beach and I wrote my thoughts in an article: We still use Planning Poker cards when the team come together, but these are used to identify differences in opinion on complexity, relative sizing etc.

  • Dennis

    I think as an agile coach this makes much sense – to re-think about the automatisms which have evolved using agile methods such as story points.

    I also believe that you have to understand what story points are for in order to use them correctly – just as some wrote, it’s something you use for estimation, release planning. Of course it can be abused and then maybe not using it at all is a better idea, as it leads away from individual team performance or even down to by person performance to product delivery performance.

    It’s interesting that the well educated team did abandon the approach of story points, but did pretend to use it for better management feedback. This basically means that the team knows the tools, but is afraid of evolving and communicating with upper management. I would expect a mature team to evolve, to work for instance iterationless or drop story points or whatever and just make this transparent.

    In the end an agile coach is a tailor which is sewing customized things to wear in a software development project. And helps the team knowing what to wear when. Later the coach leaves and people are able to tailor themselves and through an open feedback culture to educate each other on what to wear when.

  • tina

    just go back to waterfall seems u r heading that way … :)

  • Leena

    Hi Joshua,

    Thanks for posing this. We’ve been following “work on the same number of similarly-sized stories each sprint” approach and it has been working well for us. As we are an outsourcing company, one of the things that we’ve to do is to give an “estimate” while engaging with a customer. This also gets reflected in “contract” etc. We always have issues in coming up with the estimate initially, especially for a project which spans across 6-8 months, because of the same reasons mentioned by you in the post. We would definitely try the Periodic Release Planning approach you had mentioned and looks like it should help us being more accurate.

  • Eugene Nizker

    A few thoughts FWIW:

    1. Josh, the reasons you outline in the sections dedicated to story inflation, sacrificing quality and comparing team on velocity do not seem plausible to me. I think we are dealing with effect rather than cause here. The cause seems to be related to the wrong managerial practices. But then, points or not, a wrong managerial practice is going to kill the process. Any process. Especially if these wrong practices augmented by our inability to stand our ground and maintain that estimates are not commitments. For example, looking at this statement: “Our focus was on shipping, not working in a fixed timebox or tracking the number of story points completed” I can’t help thinking that the team was trying to appease the wrong metrics. So, since guillotine is a poor replacement for a hair brush I have to unfortunately disregard first three reasons.

    2. Inability to estimate in points seems more serious reason. I faced the same issue several times in the last few years, especially with teams that are new to the concept. However, my teams managed to grasp the concept and use points to their benefits.

    3. Now, what benefits? I agree that using points to predict future velocity is a practice doomed to fail. So, I use points to simply estimate the project (sprint / iteration / story / whatever). ESTIMATE, that’s it. I can then gain rough understanding of the duration – and that’s all I need! Yes, I re-estimate constantly, but the initial estimation is still very important because I need SOMETHING to communicate to my fellows in C-chairs. Now, it’s my job to educate them that estimates are just that – estimates, but that’s another story.

    4. Now, “A Simpler Way”. “Things done” instead of “story points”? I fail to see any fundamental difference between the two. Moreover, I fail to see how “things done” would be more insensitive to the wrong managerial practices we discussed than “story points”. Any system can be gamed, just
    give it time and “right incentive”.

    5. I tend to say that it’s hard to find real solution until we go beyond agile teams and beyond technology department, until we deal with managerial practices in the rest of the company. As we know, it’s impossible to drive on one perfect tire if other three are flat. Similarly, it’s impossible to successfully operate a technology arm if the rest of the company still works the same old way.

    6. At the end of the post you suggest keeping the pace and not estimating at all. Well, a business needs at least some gauge in order to function. They need to plan, they need to communicate to customers and partners, they need to prepare marketing campaigns, deal with cash flow, etc. So, if we don’t give them any estimate what do we give them instead?

    7. So, what I’m saying is we shouldn’t create deities for ourselves, be it points or anything else. At the same time, I doubt we should push the pendulum all the way and discard yesterday’s deity that easily. There may be some value in stopping somewhere half way.

  • Jennipher Marie

    Great read. The team I work with has struggled with implementing scrum because they are so agile and efficient that all the over head of estimating and planning slows them down. We started using a Kanban process the last 6 months and it has been liberating. We do still use story points (we call them donuts) to help me (the PO) prioritize and to understand if the user story needs to be broken down but we do not use them to measure velocity or break down tasks into hour calculations.

    We now focused on the most important features + leave time for hygiene and experiments every two weeks. With this new method we are releasing at least twice a week and have seen our user satisfaction and KPI’s increase.

  • Michael James

    Possible benefit #1: I have seen the velocity AND scope increase chart help Product Owners get a more realistic sense of what they might have by a given release date, generally driving a Product Owner to cut their scope forecast and/or re-prioritize.

    Possible harm #1&2: Velocity harms the development team when used as a target to increase. I suppose it could be used as a sanity check on a Sprint commitment, but even that seems to cause more harm than good. Teams that do fixed-length iterations should use their gut feel — their collective intuition — not any kind of numbers, in deciding how much to take on. At least that’s what I teach them to do.

    Possible benefit #2: I’ve seen the planning poker activity cause teams to realize items are too big, and break them into smaller pieces.

    Because I’ve seen the benefits in some specific cases, I’m not yet ready to stop telling people about relative estimation (while warning about the possible harms). Joshua’s article makes a good case and I may come the rest of the way into this camp if we continue to fail at mitigating the harm.

    It’s worth repeating that teams worried about estimation usually have bigger problems with definition of “done,” breaking work into small valuable pieces, and prioritization. If we’re always delivering a shippable product with the highest value features, estimation doesn’t matter.


  • Pingback: #NoEstimates Part 1: Doing Scrum without estimates |

  • Pingback: Velocity vs Agility | pmbag

  • Pingback: Sinn und Unsinn von Schätzungen – Teil 2 | agileXperience

  • Pingback: Algunos pensamientos sobre Story Points

  • Pingback: How can your Agile team mature? | Joe DiFalco, PMP/PMI-ACP

  • Pingback: Some good articles on Agile Development | Specialmoves

  • Chris Shinkle


    Great article and I love all the feedback and discussion going on. I think I understand your point. However, I’m curious what you would recommend for my business?

    We build custom software applications for companies. Most of the time, there is an RFP process that requires a quote with budget and schedule estimates. Sometimes these are T&M, FFP, Target Cost, or some hybrid. In each case though, the customer wants to know how much it’s going to cost and when the software will be completed. This seems like a perfect reasonable request. If I was hiring someone to do work for me, I’d want to know the same thing.

    It’s fine to hear people say stop estimating, don’t use story points, etc. But what are professional software service organizations like mine supposed to do? What’s the alternative? Please be mindful that if I told all my customers I’m not going to estimate, it’s very unlikely we would still be in business today after 25 successful years.


    • Joshua Kerievsky

      Hi Chris, this blog is fairly long and many folks don’t make it towards the end, where I do discuss ways to do estimation that are far less dysfunctional than using story points. Did you make it that far in your reading? Perhaps some of those estimation ideas could work for your business?

  • Pingback: Thought Den » Blog Archive » Making the switch to Scrum – Part One

  • Pingback: Stop Using Story Points - Industrial Logic | Innovation and Agilty in Software |

  • Pingback: Stop Using Story Points - Industrial Logic | Ag...

  • Pingback: Stop Using Story Points - Industrial Logic | Ar...

  • Pingback: Stop Using Story Points | Industrial Logic (#agile, #Lean@ | Appreciating Systems

  • Pingback: Thought Den » Blog Archive » Switching to Scrum – Part Two

  • Pingback: DevOps – How do you measure team success? | Dev Ops Guys

  • Pingback: دنیای چابک » تخمین زدن را متوقف کنید!

  • StaciaCST

    Joshua, thank you for taking the time to write such a thoughtful blog. I love it. It’s a wonderful reminder that sometimes we need to step back and look at the big picture, ask what the goal really is. A favorite exercise of late is that I’ll ask my teams to replace “agile” with “fast, focused, flexible” during discussions. This simple change opens a door to meaningful discussions about pleasing the customer that extend beyond process jargon; sometimes those discussions involve agile terms and practices, other times those discussions reveal different techniques to try, things that might not readily appear agile, but do in fact promote fast, flexible, and focused delivery. One of my most successful clients evolved into something very similar to what you described: they dropped the notion of fixed timeboxes, stopped estimating with points (it was either the right size, or too big – if too big, break it down to right size). I suppose you could say that they started with the Super Sized Agile Happy Meal and moved to Organic, Grass-Fed Agile. They saw it as a natural evolution, try this or that until we find out what works for us.

  • Pingback: September Meeting – The Puzzle Experiment

  • Pingback: Practices Change, Principles Don’t -

  • Tim Seastedt

    Hello Joshua, I have been following this blog thread with a lot of interest. My question(s) arise from needing a better understanding of how your alternative to pointing and estimating works in a setting where the executive team watches the metrics and wants to know how much product development is affecting the bottom line. We have an accounting office which wants to be able to peg costs to everything done in development. Scenario: The stakeholders put before the team a box of prioritized ‘stuff’ they want done. The teams (there are multiple, cross-platform teams which are shared resources), do not spend consecutive sprints learning and growing as a group. If no estimating is done and time is not wasted on tracking tasks in an Agile planning tool, how would you advise these teams to indicate to the executives how much this box of “stuff” is going to cost to create? Thanks!

  • Pingback: Revue de Presse Xebia | Blog Xebia France

  • Olivia Jennifer

    Yeah its a
    good article. According to you what we project managers do is communicating.
    And a lot of this communication is done during project meetings. It can
    sometimes feel like you are running from one meeting to another and that your
    time is often wasted. Meetings don’t start on time, the issues aren’t dealt
    with, there is no agenda, there is no focus, nobody assigns any follow ups or
    tasks and of course then they also don’t end on time. An efficient project manager is required for the good management of a project. I think a project manager should
    PMP certified. Looking forwards to apply what I learned in PMP classes in
    my company.

  • Pingback: #NoEstimations Does Not Stop Agile Metric Abuse

  • Ian Hawley

    I think your approach is fine. I’m not sure you can necessarily get there without decoupling from real time, which is the point of story points. Probably by trying many things you have become good at this.

    Humans are rubbish at estimating hence we use story points to estimate relative to something else and why story point values intervals increase as they rise, allowing for that.

    Just because plenty of people don’t understand them it doesn’t mean they aren’t useful or cannot be used effectively.

  • Pingback: Points of Confusion in Agile