“Walking on Water and Developing Software from Specifications are both Easy if both are Frozen”
One of the biggest pain in a developer’s life is the ever-changing software requirements, also known as scope creep. And this makes a developer’s job very difficult.
It gets worse when the developer is unable to communicate these changes and extra efforts, and it causes delivery delays. It is then often attributed to the developer’s incompetence.
So wouldn’t it be better if the developers are able to stop the scope creep in the middle of development or at least handle it better? Here are some tips for handling it better:
Do What’s Written
“What is not on paper hasn’t been said”
As developers, we always like to code rather than document. And unfortunately we often end up coding as well without any requirements documentation. When it comes to requirements, a developer should always work against documented requirements. Don’t accept verbal requirements from anyone.
Sometimes you get undocumented requirements from people you can’t force to document. In such cases document it yourself and send it for confirmation. And only begin the work after you have received the confirmation.
Do Exactly What’s Written
“If the client asks for a cat, a kitten won’t do and neither will a tiger”
It’s vital that the developer develops the Software exactly as per the requirements. The Software shouldn’t lack any feature specified in the documentation. Also it shouldn’t carry any Gold Plating.(adding extra features) .
Change Request Process
If your organization follows a formal CR process, then follow it religiously. If not, then too any changes to the requirements should be documented first and then worked on, it’s in the developer’s benefit. Any communicated changes, e.g.,
- change the error message or
- replace listbox with a checkbox or
- Change the page color scheme, etc.
should have proper documentation. Modify the impacted documents (user stories, wireframes, etc.) before starting on changes.
Re-Estimation
Whenever there is a change in a requirement, the requirement estimates are bound to change. Once the change is documented and documents modified, then re-estimate, how long will it take to implement that change.
In case if the change is resulting in time-saving then also do the re-estimation. Some such examples are functionality not needed or a complex functionality turned easier.
Re-Negotiate
Often during a sprint client comes up with a new requirement which has suddenly gained priority over others. Rather than outright rejecting it or causing yourself heartburn, the first document and estimate it. After the estimations, re-negotiate the sprint deliverables with the product owner. The new user story can always replace an existing user story from the sprint, which is of the same value but less priority for the owner.
Say No
A refusal wouldn’t go too bad if you provide some options as well. E.g., We can’t take this requirement at this juncture because all user stories are QA certified. But if it is such a high priority item than rather then waiting for four weeks we can do a mini-sprint for this item.
Put A Disclaimer