A contract for web development project using scrum

We get a lot of questions on how we organise scrum work in terms of document circulation, and what our contracts look like.

Author
Dmitrii Borodin
Founder and product owner

'A contract for web development project using scrum'

A contract for web development project using scrum

This text may seem quite confusing to people who are not experienced in document circulation and too simple for those routinely formalising contracts.

Even if it seems that there are too many papers, or everything is too complicated – it is not true. Our contracts are simple and understandable, and have the interests of both sides — the client and the studio — worked out. We promote adequacy and common sense. My policy is simple: it’s either win/win, or no deal.

Our contract templates are primarily designed for scrum works: the method of iterative development, when the project is being launched gradually, stage by stage. First stage is reserved for the most important functions, which are sufficient to get your business going and provide sales right away. New versions are systematically released over time. The list of works can be changed on the fly: you can remove or add functions, or replace them with equivalents. This allows customers to test their business idea and kickstart the essential mechanisms of it as quickly as possible. Therefore, we sign a framework contract with the customer, where we state the general terms of cooperation. After that, during individual stages of the work process, we provide and sign attachments (annexes, addendums, etc.) to our contract.

// image

Preparation of contracts and attachments

At the start of the project, along with the framework contract, we sign an appendix on requirements aggregation.

We proceed from the premise that neither the client, nor we ourselves know exactly how and in what form it is best to do the project. That’s why it is necessary to perform preliminary tasks:

  • we should allocate stakeholders, compile the project objectives, present KPI figures, if possible;
  • study user paths on the website;
  • work with semantics or use user experience models to determine the most important functions.

This job is worth the money and also is relatively cheap. It is psychologically easier for the customer to pay the first bill within the first 24-60 hours. After the aggregation of requirements is complete we have an agreed structure and a top-level roadmap of the future project. We now can specify the list of pages to be prototyped.

The second stage is signing the attachment for the development of pages’ prototypes and, if requested by the client, — the technical assignment. The classic scrum uses backlog instead of technical assignment. A backlog is a list of all features a client wants to be implemented someday. We prepare a technical assignment with a goal in mind to later restructure it into a backlog. Having a technical assignment for the project does not force us to follow it strictly. The final list of works is determined by the COST SHEETS of each individual sprint and its attachments.

// image

Next, we need to build the first version of the software product, which we will iteratively develop into something more global. I want to emphasize the importance of the first version being functional. It should be actually usable and “cool”, not a semi-finished product. Such version can be developed in a few sprints. So the result of the first sprint is not guaranteed to be eligible for delivery to real users. This somewhat contradicts the scrum concept of year 2000, but it fits with modern approaches in a much better way and is more adequately perceived by both developers and customers.

// image

So, we have signed all needed attachments: on design, layout and development of the first incarnation of the project. For large projects we provide separate attachments to sign. When we work on smaller projects, we can merge them into a single one. At the same time, we have a backlog. A backlog contains a wishlist for the next stages and, unlike the contract, is a living (dynamic) document.

// image

It’s perfectly logical that we have attachment templates for individual sprints. We collect tasks for the sprint from the backlog: state the list of works, preliminary assessments and get down to work. Sometimes, to start programming the next version you need to do analytics (to draw prototypes, for example), draw a design, and conduct a research. There can be no issues, because the structure of our attachments and contracts allows to do this. I want to highlight that the sprint works mostly go according to clear estimates of time and budget. If there are doubts, we make the analysis part into a separate stage.

// image

In most cases, an analyst can be two sprints ahead of the developers in his or her performance. The design workflow can go one sprint ahead, so programmers are basically catching up. Then, the programming is once again followed by analytics: it’s about gathering feedback from users and generating new functions. This is difficult to manage, but allows for high utilization. The manager’s workload is high and comes from both the studio, and the customer: lots of papers, lots of threads and a whole lot of things to keep in mind. But this is the price for precise estimates of terms, budgets, their fair statement in the contract and a high work rate.

Therefore, there is a reasonable alternative. After we have seated in with the client and both know what to expect from each other, it is logical to switch from iteration to kanban mode — where we get paid for whatever work is already done. We create a kanban board for the client, where he can freely introduce new tasks or set priorities.

// trello image

Large tasks will be split into sprints. Smaller ones will be solved in the order of the queue, but at a higher work rate. We provide the technical support attachment to sign for this format of work. It is designed for working on individual tasks or smaller sprints.

Don’t forget that we are talking about scrum development. Therefore, during the work, the tasklist for the next stage can be modified. In that case, the existing attachment is subject to changes, that we state in an additional agreement. Our templates are composed in such a way that basically we only have to re-sign the cost sheet.

Errors in documents can cost a bundle. Therefore, we adhere to (and so should you) the following rules of contract drafting:

  • Use generalized contract templates. Each new contract we have is made fresh from a template. We never use the contract from the previous client. Parts of the contract that can eventually change are highlighted in color to make life of project managers easier.
  • If there’s any discrepancy or unexpected nuance found in the contract, edit the template immediately. It guarantees all important changes to be replicated on all subsequent documents.
  • Audit and update templates on a periodic basis. We usually do this once or twice a year.
  • Never send contracts to customers without additional verification. You should pay extra attention to time frames, check all lines of the cost sheet and re-calculate the totals, when you check contracts and attachments (addendums, annexes, agreements, etc.).

The appendix to the article contains a gentleman’s set of documents:

  • Framework contract.
  • Attachment for the analytics process (aggregation of requirements).
  • And a complex attachment for one iteration of development.

The rest of attachments (except, perhaps, technical support and kanban mode) logically emerge from these documents.