Software projects are becoming increasingly complex. This complexity demands Agility. Agility translates to faster product increments, shorter review cycles, end-to-end picture of the product which essentially means incremental and iterative delivery. Quality needs to be built in. End user and customer engagement (via the PO) is indispensable for both building the “right product” and the “product right”.
While the IT operations are going through a paradigm shift towards Agile, has the documentations such as SOW changed to cater the needs of Agile world?
What is an SOW ? Statement of Work (SOW) is a legal binding contract between an Organization and a contingent worker or a vendor that dictates the directions of how the work will be done. So, for Agile projects, the less you write, the better off you are. Remember, the mantra is: “Less is more”. Having said that, an SOW for an incrementally-delivered project should consider the following facts when drafting one.
- What system are you trying to build? What are the common objectives? Describe the system. Include lists of themes, (feature) areas and any other important descriptions that help both the parties to understand the system better.
- Declare – loud and clear – that our development strategy is incremental and iterative.
- In Agile, neither of the parties know up front 100% of features that will constitute the final system. We negotiate that with the product Owner (PO) on an ongoing basis
- Establish the fact that features will be delivered incrementally in an iterative fashion called sprints. Define the sprint. A Sprint may range anywhere from 1 to 4 weeks of iterative cycle.
- The PO, business stakeholders and customer can review what has been created and provide valuable feedback at the end of each sprint to refine and re-prioritize for upcoming iterations.
- The project sponsor has the power to cancel the project should he/she see no further value in building this product. There should be a working agreement on how much advance notice the sponsor needs to provide to the development teams and it should ideally apply at the end of an ongoing sprint
- The customer/PO can choose to change the pace of delivery by changing priorities of upcoming features based on the review of product increment.
- The customer/PO cannot change the pace of delivery by demanding to cut corners (quality). In other words cutting out features/MMF is fine but delivering everything at a tighter pace by cutting upon quality is not acceptable
- Elaborate on what to Expect from the team. Include an initial delivery plan of features that the customer can expect from the team in the first 2 to 3 sprints in the order of priority. If possible, It is good to provide the vision, product backlog (top 3-4 sprints prioritized with 70-80% accuracy.
Including a Release plan in SOW
The SOW can include a statement that as the teams start working, they will put together a release plan to provide an insight on how the timelines look at this time. A note in bold must indicate that this is how it looks at the very beginning and that this release plan will be updated after every sprint and the updates will be made available to all stakeholders. The release plan should try to cover the below facts:
- Top 3-4 sprints with updated items(from the initial plan)
- Next 8-10 sprints prioritized with 50%-60% accuracy. Then, next 6-8 sprints could be with even lower( 30-40%) accuracy and the remaining items prioritized with 20% or lower accuracy.
- The PBI (product backlog items) should map to the product roadmap. The product roadmap should also have releases marked with farther out releases having increasingly lower accuracy (confidence rating)
Initially the big blocks of work lower in the backlog will be Tshirt sized and the teams may want to have a rough mapping of Tshirt sizes to get an arbitrary value of story point . Alternatively, affinity sizing can be used to quickly and roughly estimate a large initial backlog so the teams have some numbers to refer to as they take strides into sprints With time, as the product emerges and evolves, the PO and stakeholders get better sense of the timelines with updated release plan which has estimates with higher accuracy 
The team velocity is an important factor for creating the release plan. Prediction of team velocity is possible after first few sprints. A team’s velocity is not same as any other team’s due to various factors like experience, number of members in team, complexity of product, the technology they are working on, their style of estimation, etc. Velocity plays an important role in Agile release planning. Proper coaching by a servant leader Scrum Master is highly essential for a Scrum team to estimate consistently, plan and commit to correct capacity and then deliver to its commitment. This brings up a stable velocity and predictability which in turn provides confidence to the PO and stakeholders and they look forward to the updated release plan Agile at the end of every sprint. Servant leader Project managers and Scrum Masters must include only the details in SOW that are of Agile nature. There should be no pressure from the leadership to include details that SMs/PMs do not feel confident about. This way the Servant leader SMs won’t be held hostage by not accomplishing timelines and scope they did not think could realistically be included in an Agile SOW. The behavior of the leadership in such companies that want to really adopt a more Agile way of working should be transparent and oriented towards creating a culture where their actions are in sync with their desire to be Agile
Final Notes
Let your SOW be versioned and wait for the signatures till an agreed upon Agile SOW is in place. The first version of the SOW should be light. A small handful of sentences should suffice. If you do get push back, review your options, some of which could be:
- If it’s not win-win, educate and coach the client on why Agile contracts are more applicable to how you are working today. Walk away from the deal if there is strong insistence in signing a traditional SOW
- Suggest to the client on creating a non-legal working agreements document on how both sides can work together. What are some of the expectations that each side can fulfill to the best of their efforts? Example: The Agile Scrum dev teams can provide updated release plans, deliver to their commitments (80-100% of planned work), etc. The client should build trust as the teams are delivering with a stable velocity and understand that if updated release plans show slowness, it’s because more accurate information is available now
- This is not a great option but Agile companies still do it. Give in to the demand of the client and add fixed date, fixed scope deliverables and be prepared to work extra hours for free when things have to be reworked
