The Real Software Development Velocity is Mostly Decided by the Testing Capability, not Coding.

Especially End-to-End Test Automation.

The article’s title is not a click-bait, rather, from 16 years+ of real and proven experience. Since 2007, I have successfully developed the following apps (two are internationally acclaimed) in my spare time:

• TestWise (2006 — present, desktop app on macOS, Win & Linux)
  next-gen functional testing IDE, 2010 Ruby Award Finalist

• ClinicWise (2012–2022, web app, still in production serving customers)
  practice management software

• SiteWise (2006 — present, web app, development stopped but still in use)
  A Content Management System, all my public websites are hosted on this platform.

• BuildWise (2011 — present, web app + desktop app)
  Continuous Testing Server + Agents, 2018 Ruby Award Winner (2nd prize)

• WhenWise (2018 — present, web app)
  Easy to use Online booking system, support various business types

• TestWisely (2021 — Present, web app)
  A cloud-based Continuous Testing Platform

There are also other less-complex and internally-used apps I created such as SupportWise. Please note, I did all of the above in my spare time, solo. This is not a brag, but rather showing solid proof (over a decade, my solo-developed software are real, you can visit or download) that my software development velocity is quite high. The secret is not my coding skills, instead, my Continuous Testing process: real End-to-End (via UI) Automated Regression Testing daily (if changes were made on that day).

Table of Contents:
· Software Development Velocity based on Estimated User Story Points is silly
· It is the Testing that decides the Production Delivery Date and overall development velocity.
· Test Automation is the foundation of Agile
· A Question: “How long does a full regression testing cycle take?”
· How to shorten the regression testing time?
· FAQ

Software Development Velocity based on Estimated User Story Points is silly

Since about 10 years ago, the idea of Velocity Chart (as well as Burn Charts) has been popular in so-called ‘Agile’ software teams. I have been always against that because “software development velocity based on estimated user story points” is silly, which more and more people realize now (see info below).

Besides silliness, this idealist mindset of judging velocity on coding user stories is obviously wrong. How many times you have seen witnessed a bad check-in (causing regression issues) offset development days, weeks, or even months?

Image Credit: https://scagile.io/en/blog/calculating-scrum-velocity/

The whole velocity idea is based on a shaking foundation, ‘Estimated User Story Points”, a mostly time-wasting activity. Here is what Ron Jerferries, the creator of User Story Points, had to say about it.

My other article listed more quotes from co-authors of Agile Manifesto.

For more, I recommend Allen Holub’s keynote “#NoEstimates” presentation, (one of the best Agile presentations I have watched in recent years). Its key takeaways:

1. “Estimation is waste.”

2. “Estimation is destructive.”

3. “Counting stories is enough for projections.”

4. “Build the most important thing first.”

So, if the concept of “estimated user points” is wrong, using it to measure software development velocity is of course wrong.

Personally, I have seen so many pointless formal and long story point estimation sessions, also the meetings at the end of sprints to adjust 😔 numbers to make the velocity chart look better. To me, those are mostly just bureaucratic processes, not much related to the technical reality of app development.

A tweet by Venkat Subramaniam, founder of Agile Developer

Some readers would disagree, arguing, “How do you do software estimation then?”

My short answer is “I don’t”. Different from the reasons listed by many software experts, like this one, mine is from a practical and unusual perspective. I have such good end-to-end test automation and continuous testing process, I do ‘daily production releases”. Check out Case Study: Real “Release Early; Release Often” ClinicWise Development. First production release after 40-hour development; Then Daily Production Releases. I never cared about the production delivery date, for me, every day (if changes are made) is.

A true ScrumMaster should have known this already.

So are ‘agile coaches’, below is from Kent Beck, father of Agile.

Why most software teams couldn’t achieve that? Because their functional testing sucks, mostly done manually.

It is the Testing that decides the Production Delivery Date and overall development velocity.

I said this sentence at several meetings and conference talks, and the common reactions (two in sequential): surprised and then nodding heads. Once pointed out, it is so obvious. A bad production release is much worse than no releases. I am sure many of you can think of some cases that personally witnessed or were involved in. Anyway, here are some big ones: