Estimating User Story Points is a Waste of Time
Wise software teams spend time on activities that really matter: Test Automation and Continuous Testing
My article “Estimating Test Automation Story Points is a Total Waste of Time” featured in Software Testing Weekly has received positive feedback. One of the common questions from the readers is: “how about estimating user story points?” My answer: “It is a waste of time mostly. Try to avoid it as much as possible.”
The renowned experts’ view on “Story Points”
I know, many people will be surprised by my view and may even get offended. After all, many so-called “agile metrics” are based on story points, such as velocity charts and all the planning (based on estimates). As some people might think my view is radical, I need to borrow a few credits from the world’s top agile authorities, including Ron Jeffries, the creator of “Story Points”, to convince them.
“bloody mistake” — Ron Jeffries, co-author of Agile Manifesto and the creator of “Story Points”
2. “worrying about velocity or capacity is waste” — Ken Schwaber, creator of Scrum and co-author of Agile Manifesto.
From the above tweet, you can see the Scrum creator does not like ‘story points’ either. Ken explained more in his article.
“ we spend worrying about velocity or capacity is waste, not adding a whit of value.”
- Ken Schwaber, 2012–05–25
3. “Velocity is Killing Agility!” — Jim Highsmith, co-author of Agile Manifesto.
“they are often maniacal about measuring velocity — team velocity, velocity across teams, rolling up velocity to an organizational level or even velocity per developer (yuck). Velocity is thereby killing agility.”
- Jim Highsmith, 2011–11–02
4. “Usually estimates end up being actively harmful” — Martin Fowler
“Usually estimates end up being actively harmful as they encourage FeatureDevotion, a nasty condition where people start valuing ticking off features more than tracking the real outcome of the project.”
- Martin Fowler, 2013–02–27
5. “I may have invented story points, I am sorry now” — Ron Jeffries
“I like to say that I may have invented story points, and if I did, I’m sorry now.”
- Ron Jeffries, 2019–05–23
6. “Estimating tasks will slow you down. Don’t do it. We gave it up over 10 years ago.” — Jeff Sutherland, Inventor of Co-Creator of Scrum
“Best teams have small stories and do no tasking. They move to acceptance test driven development.
You really should read Scrum: The Art of Doing Twice the Work in Half the Time to get Scrum right. I invented Scrum to enhance team performance, not to have them suck estimating tasks in hours.” — Jeff Sutherland (link)
I have more quotes from other co-authors of Agile Manifesto (i.e., the world authority on agile), but the above shall be enough to convince most IT professionals: “estimating user stories is usually bad, very bad”.
Many might wonder: “how come the agile coaches in my current (and previous) projects spend most of their time on story points, such as estimating and calculating velocity, …,?”. Oh well, the answer is simple: “They are all fake agile coaches.”
Recommend a great presentation on Story Estimation
Since most people prefer video over reading, I recommend Allen Holub’s keynote “#NoEstimates” presentation, (one of the best Agile presentations I have watched in recent years). Its key takeaways:
“Estimation is waste.”
“Estimation is destructive.”
“Counting stories is enough for projections.”
“Build the most important thing first.”
Allen used the word “Stupid” to describe story estimation: “refusing to do stupid stuff” (at 36 min in the video). I agree based on what I have observed these years.
As a researcher (in my earlier career), I should list at least two references. Therefore, the other one is “NoEstimates: How To Measure Project Progress Without Estimating” book.
My View on Story Estimation
Besides being hands-on test automation and Continuous Testing coach, I am a programmer and the product owner of several highly acclaimed apps: TestWise, ClinicWise, SiteWise, BuildWise, and WhenWise. For all these apps, I have never estimated story points for one user story.
Besides developing my own apps, I have led the development of some commercial projects. In my opinion, estimating user story points is a waste of time too. Compared to estimation for test automation, I dropped the adjective “total” in the front of “waste”.
Despite the above testament, I would not say that I am completely against Story Estimation as the managers might need something to report. In this case, it should meet the following two criteria:
Estimate in seconds
The time of estimating user story points between two programmers should be maxed at 5 seconds, in a casual form.
How is it done?
The scrum master brings a stack of user story (physical) cards (selected for this sprint) to programers’ desks. After briefly (very brief) explaining a user story to two programmers, he asks their opinions on efforts. Five seconds to respond, with 1, 2, or 3 fingers.
That was exactly what I learned in my first Agile project, back in 2005. It worked very well.
2. Hide estimation from team members
Only one team member, typically an agile coach/scrum master/project manager, knows or cares about the story points. All other team members must never see any form of story points (such as burn charts) being used.
Why? and What’s the use of the story points then?
Wise software managers will totally forget about “Story Points” and “Estimation”. However, in reality, this might not be possible due to peer and top-level pressure.
Here is my advice to these wise managers:
Programmers’ work shouldn’t be judged against the story points.
The implementation (coding/testing) of a piece of software cannot be accurately estimated. This is the fact, accept it.
The estimation will do more harm than good in terms of software quality and ultimate velocity. The less time spent on it, the better.
If not careful, “story points estimation” could greatly slow down or even fail the project. Under the pressure of the estimation, programmers are intentionally/unintentionally encouraged to cut corners for high velocity, but tech debt will cost the team a lot more. One common frustration for me as a test automation engineer: when I presented regression failures due to a recent check-in, the programmers often ignore the defects and continue working on features. They know it is bad (a common software engineering principle: exponential cost of fixing bugs), however, they need to match the velocity expectations set by the manager or the fake agile coach. Consequentially, the programmer cares less about the product and loses pride, …, etc.Time-saving
There is no need for dedicated meetings for ‘story estimation sessions’. It has been addressed in many Agile books: the fewer meetings, the better (Don’t forget, the purpose of Standup in standup meetings is to make meetings short).A rough estimation is fine for reporting purposes
We, as human beings, will never be able to get an accurate estimation in software delivery. If some claim so, the numbers will be fraudulent. With that knowledge in mind, just make up some numbers quickly to satisfy the unreasonable reporting needs. Others do not care, anyway, how often did the estimation turn out to be correct?
Importantly though, the scrum master shall keep the information (even for the rough estimate) to himself/herself and must not let others know.Learn Test Automation and Set up a Continuous Testing process
If a bus arrives every 2 hours, you will check your watch regularly and plan activities to make sure you won’t miss one. However, if a bus comes every 5 minutes, you won’t bother that much, right? If you have experienced Japan’s bullet train which runs so frequently, you would not stress about missing a flight (still the choice for middle-range travel).
The real winning formula for IT projects enables the team to deliver releases quickly, maybe twice a day like Facebook. Real DevOps!
Make Automated E2E Testing a part of user story development. ‘Done Done’ for a user story means there is at least one automated E2E test for it.
Run all automated E2E tests (as regression testing) in a Continuous Testing server, multiple times a day.
Make fixing a broken build (on any test failures, without trying to categorize or prioritize the tests) in CT as the team’s top priority
Pushing the build to production immediately after it passes regression testing.
Stay positive; Take a small break; Then the next round.
If your customer gets a new high-quality build (with loads of newly-implemented features and updates. Yes, teams that practise test automation and CT are usually 3–10 times more productive!) every day, who would care about the estimate?!
Q & A
1. Is the agile coach in my team, who spend the most time on activities based on story points, totally unnecessary?
Yes, according to these Agile-Manifesto authors: Ron Jeffries, Ken Schwab, Jim Highsmith, and Martin Fowler, see the above. Some may argue, being famous and creating Agile/Scrum doesn’t mean they are correct. Oh well, how about an objective assessment of your project?
Try to answer this simple question: Is your project really Agile? I mean, how often do you push updates to production? Every day, or every fortnightly? By the definition of Iteration in many agile books, at the end of a sprint, the software is ready for production.
“Facebook is released twice a day, and keeping up this pace is at the heart of our culture. With this release pace, automated testing with Selenium is crucial to making sure everything works before being released.” — DAMIEN SERENI, Engineering Director at Facebook, at Selenium 2013 conference
Ultimately, an agile coach’s job is to enable the capability of quality production release frequently, ideally a couple of times per day like in Facebook (I could achieve that too).
2. Do you mean agile coaches are useless at all?
The ones who spend time on story points (and related) are useless. Real agile coaches, who spend most of their time helping with test automation and Continuous Testing, are extremely helpful. I was lucky to receive mentoring from one in 2005.