Blog

Software Rework Explained Software rework, is the consequential work that arises from altering requirements, designs, code and tests after some work has already been started.  On most software undertakings this represents 30-50% of all activity.  We generally exclude bug fixing from the category of software rework.  Rework generally describes the extra work that is a consequence of “requirements change”. Software Rework - Good or Bad Some rework may be viewed as a positive indicator that feedback from users is guiding change towards what is needed.  This is fair if the changes were unforeseeable.  However typical rework levels on software [...]

The Meaning 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 narrow and [...]

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.  By paying attention to defect detection in software requirements teams will incur less waste and more often deliver right first time. Defects Arise before Coding Starts Defects arise in requirements and architecture before coding even starts. [...]

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 [...]