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 projects are stubborn at around 30-50% of all effort. This is costing most organisations substantially more to deliver software than it should.
How Software Rework Causes Costs to Balloon
A particular problem with software rework is that it is slower or less productive than the initial development. In other words, writing code the first time is faster than to alter that code to do something else. Using a standard approach to software measurement and productivity, we can track the productivity of software teams when they do the initial build, and for the rework. Typical developer build rates are around 1 COSMIC Function point (CFP) per day (typical range: 0.7-2 CFP/day) whereas productivity on rework is lower, at 0.75 CFP per day.
When rework is required, you incur the effort to do the work first time (1 day for 1 CFP) and then (a further 1.5 days per CFP) to modify it. So the total cost becomes 2.5 days instead of 1 day.
This simple explanation shows how modest IT projects can become budget-blown disasters. By tracking requirements quality early, the probability of the disaster becomes predictable. Furthermore, by giving more attention to requirements quality earlier rework can be reduced substantially.
The Root Causes of Rework
When we become aware that some feature that we are building, or have built is not right, a decision must be made as to whether to leave it wrong, or to correct it. That later in the development lifecycle that this discovery is made, the more rework, disruption and delay is caused. It doesn’t matter whether the requirement is the result of a conversation, a written user story or a more detailed written document. The incorrectness or miscommunication is the likely root cause of the rework. Perhaps the original requirement was misunderstood, misintepreted or miscommunicated, it boils down to poor communication. Poor communication is sometimes dismissed or misrepresented as “changing requirements” when in fact it was not.
Most Change is not Genuine
Very occasionally we see a genuine unexpected change in business circumstances during a project that leads to altered requirements. However most requirements are known or knowable early. Likewise most architectural decisions that needed to satisfy those requirements are knowable (up front). Sometimes the user says “we don’t know what we need until we see it”. To discover these requirements, one must use extra elicitation techniques such as prototyping.
The vast majority of “requirements changes”, and hence rework, are caused by poor or incomplete requirements work.
Some Requirements-Related Root Causes of Rework (an incomplete list):
- Poorly articulated requirements
- Known, but unstated requirements (omissions)
- Inconsistencies across a set of requirements.
- Undeclared requirements that could have been discovered through prototyping (i.e. user needs to see something first)
- Undeclared requirements that could have been discovered through analysis
- Confusion between business objectives, functional requirements and acceptance criteria. (poor articulation).
- Confusion between functional, non-functional, constraints and tasks.
- And perhaps the only legitimate reason for rework: unknowable unknown requirements
Rework Remains Prevalent at High Levels – Rationale
Most studies will show that 30-50% of all effort on software projects is spent doing rework. There are several reasons why rework levels remain high. Some of the reasons are rarely discussed as the reasons may be uncomfortable truths.
Inconsistent Requirements Quality Standards
The industry cannot agree what makes for good requirements. One organisation that tries to promote requirements quality is the IIBA. For most people, there are no formal standards for writing requirements, and quality is generally low.
Avoiding Important Communication
Most developers like to write code, they are often introverts and not great communicators. Human interaction might not come so easily to them and they are more content doing rework than having those challenging requirements conversations beforehand.
Often developer teams will describe rework as “refactoring code”. They might accommodate poor requirements and use the excuse of: “we are agile, learning as we go”. Or they might say that the users didn’t know what they wanted until we showed it to them. The former is an excuse for “not learning before we go”; the latter is a problem more cheaply overcome with prototyping.
No Accountability For Good User Stories
The user stories are the mainstay of an agile team’s communication about what is to be built. But who is responsible for the user stories? Who is responsible for ensuring that they are correctly describing an holistic set of needs that deliver valuable capabilities? Different teams give different answers, some say the product owner, others say the whole team. Lack of clear accountability can lead to lower quality user stories, which in turn lead to misunderstandings and rework. Who is responsible for the quality of the user stories? Again, we get inconsistent answers to these questions. Revisiting the clarity of a user story, is tedious work that involves at least three team members (the three amigos). It is time-consuming and rather boring work that often happens in an ad-hoc manner, if it all. Ideally the need for these sessions is reduced by co-locating the team. With remote work co-location is essentially impossible. In some cases the product owner is a proxy representative for the real user and real subject matter expert. All lead to lower quality requirements.
Contracts That Increase Levels Of Rework
When software development is outsourced. The company to which the work is outsourced is typically paid on a day rate basis. For them the more days worked, the more days billed. There might be some contractual markers that superficially encourage efficient working, but these usually lack teeth. Ultimately it usually in the interest of the contracted organisation to incur high levels of rework. And so we often see the worst requirements on contracted engagements. In my experience there is a charade about efficient work, in reality, most contractor leads are incentivised to stretch the project out and sell more man-days. With poor requirements, rework is high and more billable hours inevitable. If you are purchasing contracted software development, beware.
Cultural Causes of Rework
If a requirement is unclear, the team should verify their understanding before doing work. Any potential misunderstandings are likely to cause rework. In some cultures, questioning the customer’s requirements is and uncomfortable conversation that they would rather avoid. Instead the team may work to assumptions and develop to those assumptions. This is particularly common on outsourced contracts. Where the requirements are written in a language that is not the mother tongue of all team members, misunderstandings (and therefore rework) is highly likely.
Reducing Rework
Observe and quantify the Problem
At the end of each sprint, ask yourselves how much work did we just do that was rework vs new work. Then ask the question, how could we possibly have avoided this. Finally record the extra effort (ie cost) that arose because you had to do the work more than once.
Embrace Standards for Writing Good Requirements
Our recommended list of quality attributes is:
- Clear
- Concise
- User-oriented
- Testable
- Measurable
- Consistent
- Complete
- Unique
- Valuable
- Design-free
With the exception of #9 in this list, ScopeMaster automatically checks your requirements for adherence to these quality attributes, so you don’t have to check them manually. (We do not recommend the INVEST list as it does not cover all the characteristics above that we have found to be important.)
Use tools that Improve Requirements
OK, so we built ScopeMaster exactly for this purpose. Using ScopeMaster you will expose and resolve 9/10 of the common quality types listed above and at a rate of about 10x faster than doing so manually. In short, you can expect to reduce rework dramatically by using ScopeMaster to help you assess and refine your requirements. There are other tools from QVScribe and even IBM Doors, but these only scratch the surface of what ScopeMaster does.
Write Contracts that Incentivise Low Rework
There are several ways of tackling this problem. First, is to be acutely aware that it is a concern. Remember that most rework is avoidable. We have a package of contractual recommendations that can help you shape your outsourced development contracts to minimise the likelihood of rework.
Quantifying Rework
We have seen that rework caused by poor requirements causes effort increase from 1x to 2.5x. This actually a modest estimate, because when you change direction the disruption to one block of code can have a negative impact on other parts of the codebase, causing even further rework.
Predicting Defects – Using numbers to reduce rework
Studies have gathered data on the creation as well as the removal of defects. These have shown that defect potentials occur in each of the key software development artifacts: requirements, design, code, tests. The consequence is that we know the defect potentials of each and therefore, how many defects we need to remove until we reach a satisfactory quality. Again, using standard sizing we know that typical defect potentials are approximately 5 defects per CFP of which 1 is likely to be in the requirements. We also know that the average size of a user story is 5.5 CFP, and so we have a requirements defect potential of 5.5 per user story. This means that unless we are proactive, those 5.5 defects will remain and become rework later on. Tools such as ScopeMaster can find about 50% of the defects in requirements, ie 2-3 per user story. This halving the likely cause of rework.
Summary and Conclusion
Rework represents as much as half of all work on software projects. This has not reduced much over the years. The root cause of most rework is poor communication caused by inadequate discipline and diligence with requirements. There are many reasons why teams do not try harder to improve requirements. Most of this rework is avoidable, especially now with the help of tools such as ScopeMaster that can help you find and fix problems with requirements faster, earlier and more thoroughly than manual measures.
Written by Colin Hammond, 35 years of IT experience and founder of ScopeMaster.
