A Practical Advice on Rejecting Estimating Story Points for Test Automation

Many years ago, I worked in a small start-up company on its client project. B, A co-founder (without coding/testing background), was particularly fixated on story points. His actions led me to believe that he thought he had cracked the secret code of software development, which was "Velocity based on User Story Points", as the project went very well.

The main success factor, as the staff told me (and almost in all previous client projects), was the E2E Test Automation I implemented that enabled quality releases every sprint. Besides that, my daily E2E test automation regression tesing (running in BuildWise CT Server) picked many regression defects on a daily basis for the other three sister-projects, which made this start-up shine.

Readers might think I am bragging. Check out this article, Analyses of the Wired Article: "The Software Revolution Behind LinkedIn's Gushing Profits"

B ordered a printing out of a stack of "Story Estimation Cards" like the one below, with a Fibonacci sequence number and company logo at the back. B was very proud of "this product", making staff use it in the 'story points estimation' sessions.

The Fibonacci sequence is one popular scoring scale for estimating agile story points. This sounds like ‘an urban myth’ to me. This really no logic behind that, which make this act more silly.

Here is a part of the conversation when B (acting as the scrum master, as I said early, it is just a small start-up) asked me to provide estimations for test automation efforts.

“Z (my nickname), what is the story point of test automation for the user story #123”.

“2”, I replied.

“OK” (noted in JIRA)

…

“Z, your estimate for story #125?”

“2”, I replied.

My estimate is always “2” (or whatever numbering scheme they are comfortable with). Of course, very soon, understandably, the scrum master was not happy.

“Z, be serious, the test automation estimate for #126?”

“2, my answer will always be 2”, I replied. “Test automation is different from manual testing. Over 95% of my time as a test automation engineer will be spent on regression testing/maintenance, i.e., not on this sprint. So the estimation has absolutely no meaning to me”.

Then I explained with charts (showed the above). Like most of the audience who attended my training and presentation, the team members agreed mostly and uncomfortably. B was unhappy.

It is like some things in our life, once it is pointed out, it is painfully obvious. For the estimation session, the scrum master accepted two as the story points for test automation (for each user story).

My action was a big surprise to all the team members. Some might wonder why. As some of you now know, "Story Points" was mostly a mistake, and its creator "Ron Jeffries" even apologized for it.

I was unaware of this information to back me up to challenge the super-hot User Story Points, then (maybe before 2014).

Back to the story. Not surprisingly, I was told that I was no longer required to attend the "story estimate sessions." I was happy that I had more time for testing. The "scrum master" would be happy too. Without my presence, he could continue doing his version of 'Agile Planning'.

I suggest others do it more diplomatically, as my approach was too direct. Because estimating story points for test automation was so stupid, after you revealed out, people would be embarrassed. Advise your manager privately.

Related reading

• Estimating User Story Points is a Waste of Time
• What is my Agile Way? Production Deployment within the first week, then every working day
• Why I don't use Jira and Confluence at all for my software development?
• Why Don't I Use Defect Tracking? No Need, I do real Continuous Testing.