Blog

The Meaning and Origin of "Technical Debt" The metaphor of Technical Debt (TD) in the context of software was coined by Ward Cunningham who at the time was working on coding a financial system. He used the metaphor to explain to his financial colleagues the reasoning for refactoring and rewriting parts of codes as the knowledge of the requirements evolved. "When taking short cuts and delivering code that is not quite right for the programming task of the moment, a development team incurs TD. This debt decreases productivity. This loss of productivity is the interest of the TD." Ward's original intended explanation was fairly [...]

Here are some insights into the value of finding requirements defects  before design or coding. To a software development team it is very valuable to find defects early.  Even better still, is to prevent defects altogether.  Excellent requirements are an effective form of defect prevention and rework prevention.   An ambiguous requirement can lead to substantial wasted effort. Defects Arise before Coding Starts Defects arise in requirements and architecture before coding even starts.  Let us imagine we are in an insurance business, and the business folks have decided that a new (or changed) system [...]

Story splitting - refinement to an optimal granularity An apparently small story may turn out to be much bigger than expected. Only by refinement or story splitting can you discover this. Story splitting can be done early or just before the preceding sprint. We recommend doing it as early as possible to avoid late surprises. We consider "story splitting" and "story refinement" as very similar activities. It's about optimising the granularity of the written user story. What are user stories For those teams that are able to colocate, the user story can be just a reminder of a conversation. [...]

Requirements Elicitation is about discovering the real business requirements and the system requirements of any software endeavour. It is first about discovering what is needed and then about articulating the distilled discoveries into a artefacts that can be used as the basis for describing what needs to be done.  It is unusual that the real business requirements (and subsequent system requirements) can be rapidly found.   Although requirements elicitation is sometimes referred to as requirements gathering, this is a misleading phrase.  The real requirements are more like buried treasure in a field as apposed to crops that can be reaped.  Sometimes an indication of [...]

Let us look at how and why we might want to quality assure user stories.  Poor user stories lead to unnecessary meetings, waste and rework.  Improving user story as early as possible in the development lifecycle is an effective way of minimising waste and rework. Quality assurance is a systematic approach to determine if a "product" meets acceptable criteria.  For the QA of user stories we need to first define what does good like?  What is the difference between a good user stories (and set of user stories) vs poor quality. For agile software development we tend to [...]