Agile SOW

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 Agile release plan 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 

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 

Amitabh (Amit) Sinha is a servant leader entrepreneur, visionary, mentor, trainer and coach. Amit is highly passionate about Agile, its principles, values, and the human side. Amit is a people champion and strives to bring out the best in his teams. Amit leverages his expertise in Agile, Scrum, Kanban and people skills to increase team effectiveness and happiness. See more

Agile SOW

Challenge Your Understanding About "Agile SOW" By Taking This Short Quiz!

1 / 5

Question 1: What is the primary purpose of a Statement of Work (SOW) in Agile projects?

To define the project's budget in detail.

To outline the scope, objectives, and deliverables of the project.

To list the names of all team members involved.

To provide a detailed timeline for each project phase.

To specify the tools and technologies to be used.

Answer: B) To outline the scope, objectives, and deliverables of the project.
Explanation: An SOW serves as a foundational document that clearly defines the project's scope, objectives, and deliverables, ensuring all parties have a mutual understanding of the project's direction.

2 / 5

Question 2: In Agile methodologies, how are project features typically delivered according to the SOW?

All at once at the project's completion.

In a sequential, non-iterative manner.

Incrementally and iteratively through sprints.

Only after all testing is completed.

As per the client's initial requirements without changes.

Answer: C) Incrementally and iteratively through sprints.
Explanation: Agile projects emphasize delivering work in small, manageable increments through iterative cycles known as sprints, allowing for regular feedback and continuous improvement.

3 / 5

Question 3: Which statement best reflects the flexibility allowed in an Agile SOW regarding project features?

All features are fixed at the project's start and cannot be changed.

Features can be negotiated and reprioritized with the Product Owner throughout the project.

Only minor features can be adjusted after initial planning.

Changes to features require a complete rewrite of the SOW.

Feature changes are discouraged to maintain project stability.

Answer: B) Features can be negotiated and reprioritized with the Product Owner throughout the project.
Explanation: Agile encourages flexibility, enabling teams to collaborate with the Product Owner to adjust and reprioritize features based on feedback and changing requirements.

4 / 5

Question 4: What is a recommended practice for including a release plan in an Agile SOW?

Detail every feature to be delivered in each sprint with 100% accuracy.

Provide a high-level release plan that is updated after every sprint.

Avoid mentioning a release plan to maintain flexibility.

Include a fixed release plan that should not change.

Specify exact delivery dates for all features upfront.

Answer: B) Provide a high-level release plan that is updated after every sprint.
Explanation: Including a high-level release plan in the SOW, which is regularly updated, offers stakeholders insight into timelines while accommodating the adaptive nature of Agile projects.

5 / 5

Question 5: In the context of an Agile SOW, what is the significance of the Product Backlog?

It lists completed tasks ready for client review.

It contains all pending issues and bugs to be fixed.

It outlines future work items, prioritized and refined over time.

It is a static document that doesn't change during the project.

It details the project's financial expenditures.

Answer: C) It outlines future work items, prioritized and refined over time.
Explanation: The Product Backlog is a dynamic list of future work items that are continuously prioritized and refined, guiding the team's development efforts in alignment with project goals.

Your score is