Secret ingredients to quality software


Management - Do you use Just-In-Time speccing?

Last updated by Tiago Araújo [SSW] on 18 May 2021 07:36 pm (about 1 month ago) See History

The first problem with specs is that nobody writes them. Joel Spolsky says:

"Writing specs is like flossing: everyone agrees that it's a good thing, but nobody does it". - Joel Spolsky,  The Joel Test: 12 Steps to Better Code

The second problem is that when people do write them, they try and spec the whole project, spending months detailing every Use Case, Business Rule, and Process Flow Diagram. The client spends lots of money and sees no real progress, and the requirements change and the process begins again.

After a long phase of planning and speccing, hand-offs between stages of a project would traditionally involve wighty documents and getting a project from start to finish could take months or years. By embracing "Emergent Architecture" and using an agile approach to project management you spec just enough, at the last responsible moment. Just-in-time speccing ensures:

jit speccing
Figure: Just-In-Time speccing in an agile Scrum project can handle evolving requirements

The most popular and most successful way to deliver projects is using a framework called Scrum. In Scrum, you fix the timeframe and the cost so the only variance is in the features that are delivered in that time. You should keep your time to between 2 and 4 weeks and all your team members should be full time, thus fixing the costs.

See Rules to better Scrum.

At SSW we spec in two phases: first to get an overview of the project, and then ongoing as needed to flesh out each PBI once it is about to be added to a Sprint:

  • Spec Review
  • Just-In-Time Speccing - this phase is repeated through the project
Adam CoganAdam Cogan
Jayden AlchinJayden Alchin

We open source. This page is on GitHub