The DocuStream Blog

News, case notes and articles on technology and telecommunication law

How software developers can deal with scope creep April 10, 2016

We act for many software developer clients. Often the first time we hear from a software developer is when they contact us to inform us of a "scope creep" dispute. 

Scope Creep

Scope creep is almost inevitable in a waterfall model software development project because it is not until the software is delivered that a client will think about changes to the scope, or extensions of the functionality of the software, that will enhance the software and therefore the client's potential for earning revenue from selling or licensing the software.

The problem this creates for software developers is that it places an expectation on the developer to spend additional time on the project that it did not anticipate when the fees were agreed. Frequently, the issue of scope creep will embroil the parties in a dispute over:

  • What the developer in fact agreed to develop
  • What is in or out of scope
  • How much the client ought to pay the developer for 'out of scope' functionality
  • Who will own the enhanced version of the software
  • When additional fees are due for payment for the 'out of scope' functionality
  • If there is both a developer and a software designer involved, whose obligation it is to develop any consequential design changes to the software
  • What impact the scope creep has on the developer's obligations to provide warranty and support services

Agile methodology

If we know that functional and non-functional requirements are going to change over time no matter what is agreed at the outset, rather than set ourselves up for disputes, a solution needs to be found to deal with evolving requirements for the benefit of both the developer and the client that encourages change within an agreed framework. That's where agile software development comes into play.

With agile software development, there is a common software vision, but no finite agreed functional specifications at the outset.  Rather, the specifications evolve over time before each software sprint and are defined in each sprint meeting. One way that some agile software development projects sometimes operate is where the parties agree that a series of sprints will be carried out and that the developer is bound to work up to a maximum number of sprint hours over the course of the sprint. At each sprint meeting, the client can prioritise the work that is to be carried out over the forthcoming sprint. 

Our Agile Software Development Agreement template is a good starting point for your next agile software development project. It comes with 30 minutes of free legal advice and can be downloaded customised using DocuStream - our document generation platform.

The information on this blog does not take into account your specific requirements and does not constitute legal advice and nor is it a substitute for legal advice. Readers should obtain legal advice on their specific circumstances.