Five Steps to Creating Effective Agile Contracts

Step Three: Define Roles and Responsibilities

Regardless of the type of project management method used, it’s important to establish clear definitions of roles and responsibilities in a contractual agreement between an organization and an outside party, such as a consulting company. This is typically the part of the contract that describes which party will be doing what.  When an organization is using an agile approach like Scrum, it is especially important to define which party will provide the product owner.  This individual has a great deal of power in Scrum because he is responsible for defining the overall direction of the product as well as accepting (or rejecting) individual requirements as done.

Being a product owner is time-consuming, and consulting organizations should think about this carefully before they suggest their clients take the product owner role.  The reality is that it is almost always more work for a consulting company to have a client-side product owner, rather than having responsibility for that role. Clients are often still learning Scrum, and they may be unsure how to write good product backlog items and acceptance criteria. Sparse and poorly written product backlogs can result from a client unversed in using Scrum, and who has other demands to attend to. Despite the fact that this is the product owner’s responsibility, consultants are often blamed and used as scapegoats.

That being said, individuals from the client side can make good product owners. They can be excellent at controlling costs, as product owners are also responsible for the return on investment of the project.  Unlike a representative from the consulting organization, these individuals should have no trouble telling their stakeholders that a particular requirement is not cost effective when added to the project.

If you choose to have a client-side product owner, be sure to schedule regular product backlog grooming sessions to ensure the backlog is properly maintained.  Unlike a sprint planning meeting, grooming sessions do not involve making commitments for a sprint.  Rather, the purpose of these meetings is to improve the product backlog.  Schedule one of these meetings every sprint so that it happens at least a few days before the sprint planning meeting.  Doing so will help a client product owner get his backlog in working order and will help to build the collaborative relationship between the Scrum team, product owner, and ScrumMaster.  It will also ensure the product backlog reflects the work being done in the project, thereby improving the audit trail.

Step Four: Use a Sprint to Build a Statement of Work

For consulting agencies, the statement of work (SOW) is a high-level description of the work a project entails.  It usually contains some reference to the procedures that will be followed, including handoff points, roles and responsibilities, and estimates.  Many audit processes require a signed SOW before work can begin or be billed for a project.  When using an agile approach like Scrum, it helps to use the first sprint of the project to create this SOW.  Do not mistake this for a “requirements” sprint—it is much more than that.  During a SOW sprint, the two parties can define the high-level business problem or opportunity, assemble a team, write the beginnings of a product backlog, define roles and responsibilities, and create high-level estimates. The SOW itself is the output (or sprint goal).

When using an agile approach, using an SOW sprint is one of the biggest cost savers for clients.  Methods like Scrum were created because it is hard to dream up all the requirements before ever starting a project.  For this reason, the requirements phase of a project tends to drag on for weeks and sometimes months as clients try to think up every little thing they might possibly want included.  In reality, many of these features are not essential to the project, and they raise the cost without giving commensurate value.  By timeboxing this effort to a single sprint and letting the client know that additional requirements can be added later, everyone can focus on understanding the project goal.  Client organizations have seen their project costs drop by as much as 30 percent by using this method. 

Having a successful SOW sprint requires the full involvement of everyone during that time period.  Because time is limited to a single sprint of perhaps two weeks, this should be considered a full-time effort for the identified Scrum team, the ScrumMaster, and the product owner.  Stakeholders should be informed ahead of time of the schedule boundaries and when they will be needed. Finally, be sure to allot time for whoever will write the SOW, which oftentimes can be the ScrumMaster.  Just be sure to allow ample time at the end of the sprint for this task.  Ideally, the sprint review at the end of this effort will result in the product owner’s or other required parties’ signing the SOW so that actual development can begin the next day.