To bring another software development practice principle, there’s a concept of Single Source of…
Jeffrey Qua

You are SO right Jeffrey Qua!

At we actually recently interviewed dozens of software teams to learn what their greatest challenges were in delivering software quickly, whilst also delivering at high quality. One of the top challenges cited was having no Single Source of Truth for specs and requirements.

No SSOT is a specific problem in a high-pace product/software team because requirements, designs, specs etc are always changing and iterating over time, as of course they should be! Then add in the challenge that those artifacts will live in a variety of forms and locations, including word docs, Invision prototypes, whiteboards, spreadsheets, confluence pages, Jira tickets — and everyone’s favorite — the back of the napkin.

This is not a problem in itself, as long as the whole team knows which of those artifacts is the current truth that everyone is building for. I’ll be sharing more from that study soon, but for now the pertinent point for this discussion is that the SSOT is even more problematic, if some of those artifacts never existed in the first place, for example if defining requirements was skipped and the team moved straight into design.

Thanks again for your feedback, mate. Chris.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.