Unit of Work Pricing Model Vs Agile Scrum Methodology

IT is faced with a real challenge of reducing its costs and getting the most value out of its investments. We have come a long way in defining the new pricing models to embrace this new challenge.

Through this article, I would like to share the benefits of a two-fold approach for execution of small and large projects. Unit of Work (UOW) Pricing Model has helped clients a long way to minimize the costs and has an effective approach defined for execution and delivery of manageable units. At the same time, Agile Scrum methodology is so widely accepted these days in the Software industry.  An Agile Scrum approach compliments this kind of a pricing model. Contracting can be based on the number of User stories. The tricky part is to come up with appropriate User Stories. Good amount of team effort is required to achieve the same. Sprint Scope can be pre-defined for such User Stories.

Consider a typical Waterfall - Fixed Price Project. When we apply the Agile Scrum Methodology to this kind of a project, a typical implementation looks like below. All the Sprints are deployed in Production as a Singe Packaged Release.

Figure1: Agile Scrum Implementation for Generic Fixed Price Project

Now, when we apply the Agile Scrum Methodology to the Unit of Work Pricing model, a typical implementation looks like below. Each Sprint or Multiple Sprints can account to a Single Release.

 

Figure2: Agile Scrum Implementation for Unit of Work Pricing Model

In this implementation, be it the Execution or Tracking or Change management, it gets easier and accountable. This helps in achieving great customer satisfaction. Customer becomes part of every execution and embraces the beauty of the delivery. Cost comes down drastically especially with respect to change management.

Based on my experience, here are few practices which we should follow to achieve the most out of this two-fold approach or Agile Scrum methodology:

1. Good amount of workshops with Customer to be held for coming up with a Sprint Structure and Customer should be involved for defining the user stories
2. Sprint Planning should be done with some defined overlap of Sprint Cycles in order to give room to incorporate some critical feedback
3. Design and Technical dependencies between different Sprint cycles should be thoroughly reviewed and accommodated in the to-be executed cycle or as a new requirement
4. Changes or Defects should be taken up as a new requirement
5. Sprint Stand-ups and relevant Sprint Reviews to focus on continuous improvement
6. Keep the Customer informed of the progress and issues during Sprint execution for timely resolution
7. Customer feedback at every juncture or release is an important key to success
8. Its good to keep the Sprint duration constant, at least for the first few iterations, particularly in new product/service development scenarios - this sets the right expectations, gives us the room for continuous improvement and also gives us the opportunity to block the time for Key stakeholder discussions ahead of time. However as we move to the end of the project, the Sprint Cycle duration can be reduced.

There is nothing magical in this approach however proper planning should be done in order to reap the benefits.