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?

2 / 5

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

3 / 5

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

4 / 5

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

5 / 5

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

Your score is

5 3 votes
Rating
Subscribe
Notify of
guest
Rating

4 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Rohit
Rohit
3 months ago
Rating :
     

This blog provides an excellent breakdown of how to adapt the Statement of Work (SOW) for Agile projects. I especially appreciate the emphasis on flexibility and the importance of keeping things light and iterative. It’s so refreshing to see a focus on collaboration and continuous feedback between the team, Product Owner, and stakeholders. The insights on incorporating features incrementally, adjusting priorities, and updating release plans after each sprint really highlight how Agile can lead to better outcomes. I’m excited to apply some of these tips to our own projects!

Amit Sinha
Amit Sinha
Reply to  Rohit
3 months ago

Thanks Rohit. Keep up the new direction and do not hesitate to reach out should you need any help. The “contact-us” form is a good way to reach us.

Diana
Diana
2 months ago
Rating :
     

This blog explains how to adapt the Statement of Work (SOW) for Agile projects, focusing on flexibility, iterative processes, and collaboration. It covers delivering features incrementally, adjusting priorities, and updating release plans after each sprint for better outcomes. Great insights for improving Agile project management!

Lara
Lara
2 months ago
Rating :
     

Great insights on drafting an SOW for Agile projects! Love how you highlight the importance of incremental delivery, sprint cycles, and Product Owner (PO) collaboration. Keeping it concise while ensuring quality is key—thanks for sharing these actionable tips!

4
0
Would love your thoughts, please comment.x
()
x

Transform Your Team, Elevate Your Business!

Subscribe to the Agilonomics Newsletter and Claim Your Free Power Team Consultation Today!

We promise to keep your email address safe. You can check our Privacy Policy.

Thank you for subscribing to our Agile Wisdome - Weekly Tips!

You’re almost there! Please check your email and click the confirmation link to complete your subscription. If you don’t see the email, be sure to check your spam folder.

Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognizing you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Strictly Necessary Cookies

Strictly necessary cookies are enabled at all times so that our website can function optimally.

3rd Party Cookies

Our website uses Google Analytics to collect useful information. These cookies are used by us to build a profile of interest and show you relevant offers.

Keeping these cookies enabled helps us to improve our website and your experience.