How Much Does This Cost?

“There  are  so  many  men  who  can  figure  costs,  and  so  few  who  can  measure  value”  –  
Unknown  
 
Contracts,  budgets  and  quotes.  These  three  concepts  can  send  the  most  ardent  
#NoEstimates  practitioners  running  for  cover.    
 
They  shouldn't.  
 
Understanding  outcomes,  value  and  trust  is  the  key  to  successfully  building  a  contract  
around  #NoEstimates,  or  any  adaptive  and  agile  delivery  model.  Without  them,  an  
organisation  is  naturally  constrained  in  their  ability  to  adapt  and  leverage  a  changing  market.  

The context of contracts

Fundamentally,  a  contract  is  defined  by  the  level  of  risk  each  party  is  willing  to  accept.  To  
manage  this  risk,  there  are  three  questions  that  every  customer  will  ask  an  agile  project  at  
some  point.  
1.   "How  much  will  this  cost?"  
2.   "How  long  will  it  take?"  
3.   "What  am  I  going  to  get?"  
And  while  "as  much  as  you're  willing  to  spend",  "as  long  as  necessary"  and  "whatever  you  
ask  for"  are  sometimes  acceptable  answers,  many  customers  are  uncomfortable  with  this  
approach.  This  reflects  more  on  the  customer  than  the  team,  but  has  often  led  to  the  
misconception  that  agile,  or  #NoEstimates,  teams  are  writing  themselves  a  blank  cheque.  
How  then  should  you  define  and  scope  a  project  where  the  customer  expects  fixed  time,  
cost  or  scope?  
 
Let's  be  clear  about  the  basics  first.  There  is  a  fundamental  relationship  between  time,  cost  
and  scope.  To  understand  this,  it  can  help  to  visualise  your  project  as  a  pipeline,  as  shown  
below.  The  width  of  the  pipe  is  your  team  size,  the  length  is  the  time  available  to  deliver,  and  
the  flow  is  your  scope.  Any  variations  require  one  of  these  three  variables  to  change.  
Effectively  (and  simplistically)  you  have  three  options;;  increase  capacity  (cost),  increase  
duration  (time),  or  drop  requirement  (scope).  In  agile  terms,  your  velocity  doesn't  change  just  
because  you  add  more  work.    
 
  
Figure  1:  The  relationship  between  time,  cost  and  scope  
 
As  an  aside,  most  research1  suggests2  that3  sustained4  overtime  work  can  lead  to  a  
significant  reduction  in  productivity.  
 
We  also  need  to  understand  that  every  project  has  constraints  and  that  these  are  not  
necessarily  a  bad  thing.  Creativity  and  innovation  are  supported  and  spurred  by  the  
constraints  we  have  to  deal  with.However,  by  definition,  agile  delivery  practices  put  the  
customer  in  control  of  the  product  and  do  not  constrain  scope  beyond  setting  project  context  
at  the  start.  The  functionality  of  a  product  may  evolve  as  the  backlog  changes  between  
iterations.  Even  the  agile  manifesto  states  this  very  clearly;;  customer  collaboration  over  
contract  negotiation.  
 
In  other  words,  the  scope  of  the  project  is  unpredictable.  I'll  go  further  and  state  that  all  
projects  are  unpredictable,  but  waterfall  contracts  cover  their  eyes  and  go  la  la  la  and  
pretend  that  everything  is  fine.  
 
So  what  does  this  mean  for  contracts?  Contracts  rely  on  predictability,  I'll  pay  you  X  to  do  Y,  
which  demonstrates  a  fundamental  flaw  in  how  we  traditionally  build  contracts.  So  for  an  
agile  contract,  we  need  to  find  a  different  constraint  -­  a  different  way  of  agreeing  to  a  
commitment.      
 
But  let's  start  where  all  contracts  should  start;;  trust.  

A matter of trust
In  large  part,  the  form  and  flexibility  of  a  contract  between  parties  depends  on  the  level  of  
trust  that  exists  between  them.  This  can  be  defined  across  four  distinct  levels.    
 

                                                                                                     
1
 Better  Work  Discussion,  Seo,  Paper  Series  No.  2  (2011)  
2
 Overtime  Work  and  Incident  Coronary  Heart  Disease:  the  Whitehall  II  Prospective  Cohort  Study,  
Virtanen,  et  al  (2010)  
3
 Effect  of  Overtime  Work  on  Cognitive  Function  in  Automotive  Workers,  Proctor,  et  al  (1996)  
4
 Effects  of  Workload  and  8-­  Versus  12-­h  Workday  Duration  on  Test  Battery  Performance,  MacDonald  
and  Bendak  (2000)  
  
Figure  2:  The  trust  pyramid  
 
1.   Reference:  This  is  the  lowest  form  of  trust  and  exists  where  trust  between  the  parties  
is  based  on  the  reference  of  a  mutually  trusted  third  party.  
2.   Contract:  This  is  the  most  common  level  of  trust,  and  the  majority  of  relationships  do  
not  extend  beyond  this.  This  exists  where  parties  create  legally  binding  contracts  
(potentially  with  penalty  clauses)  as  the  core  mechanism  to  enable  trust  between  
them.  
3.   Identification:  This  level  of  trust  is  created  over  time  and  exists  where  parties  have  
the  opportunity  to  work  together  and  build  trust  based  on  personal  experiences.  
4.   Partnership:  This  is  the  highest  level  of  trust  between  two  parties  and  exists  when  
both  parties  share  the  same  goals  and  outcomes.  This  may  take  the  form  of  a  
strategic  partnership  or  similar  structure.    
 
Understanding  the  levels  of  trust  is  essential  in  developing  agile  contracts.  

Developing agile contracts

This  brings  us  to  the  core  of  this  essay  -­  the  contacts  themselves.  Experience  shows  that  
most  software  contacts  come  in  three  forms.  Time  and  materials,  outcome  based  or  fixed  
contracts.    

Time and material contracts

Time  and  materials  (also  known  as  T&M)  is  the  most  “agile”  contract  model  and  provides  the  
greatest  flexibility  to  change,  scale  and  adapt  on  demand.  If  you  are  able  to  identify  and  
prioritise  the  value  of  a  user  story,  a  T&M  contract  gives  you  the  flexibility  to  stop  work  (or  at  
least  trigger  the  contract  closure  clauses)  as  soon  as  the  cost  of  delivery  is  greater  than  the  
value  of  what  is  delivered.  In  other  words,  work  should  continue  until  the  customer  chooses  
to  stop.  
 

 
Figure  3:  Cost  vs.  value  
 
To  understand  what  this  means,  it  can  help  to  visualise  the  rate  of  spending.  In  the  above  
simple  example  we  track  the  value  of  each  story  against  a  linear  financial  spend  (fixed  team  
size).  In  this  example,  quite  common  among  software  projects,  the  initial  stories  are  of  low  
value  (technical  framework  or  database  tasks),  followed  by  simple,  yet  high  value,  tasks,  
followed  by  the  lower  value  and  harder  tasks.  In  this  example  it  is  very  easy  to  see  where  the  
T&M  contract  should  come  to  an  end  as  the  value  diminishes  against  the  cost.  
 
If  additional  controls  are  needed,  you  can  create  a  capped  T&M  contract  which  limits  the  
spend  to  a  fixed  amount.  What  is  critical  in  this  style  of  contract  is  to  ensure  that  the  cap  is  
high  enough  that  the  overall  return  on  investment  is  positive.  And  because  you  can  always  
spend  less,  it  should  be  at  the  upper  bound  of  what  is  agreeable  to  both  parties.      

Outcome-based contracts
Gaining  popularity  in  recent  time  is  the  use  of  outcome-­based  or  performance-­based  
contracts.  These  are  sometimes  known  as  "power  by  the  hour"  in  reference  to  the  support  
contracts  for  aircraft  engines  that  are  based  on  the  hours  flown  rather  than  fixed  or  
annualised  contracts.  
 
The  difficulty  is  defining  an  outcome  which  is  measurable  and  mutually  acceptable  from  the  
financial  perspective.  
 
Common  examples  of  outcome-­based  contracts  are  Software-­as-­a-­Service  and  other  pay  
per  use  models.  Referring  back  to  the  levels  of  trust,  for  outcome-­based  contracts  to  be  
successful,  organisations  need  to  be  near  the  top  of  the  trust  pyramid  (see  Figure  2)  at  the  
level  of  partnerships.  
 
In  developing  an  outcome-­based  contract  you  will  need  to  set  the  following  parameters;;  
●   The  expected  outcome:  Fairly  obviously  you  need  to  define  the  outcome  that  you  
are  measuring.  
●   The  outcome  measures  and  levels:  How  will  you  measure  the  performance  of  the  
outcome  and  how  are  these  rated  against  the  contract.  
●   The  payment  curve:  how  will  you  pay  (or  be  paid)  against  the  performance  
measures  and  levels  above.  Also  are  there  sufficient  incentives  to  exceed  the  
baseline  measure.  
●   The  risks  to  the  outcome:  What  risks  are  you  willing  to  accept  (especially  relating  to  
difficulties  in  measuring  the  outcome)  

"Fixed" contracts
The  sad  fact  is  that  many  customers,  especially  those  at  the  lower  levels  of  the  trust  pyramid  
or  where  there  are  significant  capital  costs,  require  "fixed"  contracts.  In  the  standard  case  
this  is  a  combination  of  fixed  cost,  time,  or  scope.  Providing  fixed  quotes  can  sometimes  be  
compatible  with  #NoEstimates,  but  requires  careful  attention  to  manage  well  the  flexible  
component  in  a  way  that  is  reasonable  and  achievable.  There  are  7  forms  of  fixed  contracts.  
These  are:    
 
1.   Fixed  cost:  Where  your  customer  asks  for  a  fixed  price  quote,  prior  to  work  
commencing,  but  is  flexible  on  the  scope  of  delivery,  and  how  long  it  takes.  
a.   For  example:  Provide  operational  support  and  maintenance  services.  
b.   How  to  quote:  Identify,  and  estimate,  the  approximate  user  stories  in  iteration  
0.  Use  this  to  calculate  the  cost  to  deliver.  
c.   How  to  deliver:  Keep  iterations  short  (1-­2  weeks)  as  longer  iterations  have  a  
tendency  to  cost  overruns.  Additionally,  reducing  the  time  spent  on  technical  
debt  and  refactoring  tasks  can  also  help  meet  short-­term  budget  constraints,  
at  the  cost  of  long-­term  efficiency.    
d.   How  to  measure:  Monitor  velocity  and  burn  rate,  as  these  are  your  key  
indicators  of  cost.  Constantly  adjust  scope  and  time  based  on  what  you  
measure.  
2.   Fixed  time:  Where  your  customer  asks  for  final  delivery  by  a  specific  date,  but  is  
flexible  in  scope  and  cost.  
a.   For  example:  Design  and  print  new  marketing  material  for  a  product  launch.  
b.   How  to  estimate:  Using  historical  velocity  data,  each  team  can  forecast  the  
number  of  stories  they  can  deliver  by  the  due  date.    
c.   How  to  deliver:  Strictly  enforce  timeboxes.  The  duration  is  defined  by  a  fixed  
number  of  iterations,  and  extending  an  iteration  will  push  out  your  final  date.  
d.   How  to  measure:  Tracking  team  and  project  velocity  and/or  cycle  time.  
3.   Fixed  scope:  Where  your  customer  has  a  fixed  set  of  requirements,  but  is  flexible  in  
the  time  it  takes  to  deliver,  and  the  cost  of  delivery.  This  is  sometimes  known  as  
‘heavy  agile’.  
a.   For  example:  Change  existing  reports  to  accommodate  internal  reporting  
requirements.  
 b.   How  to  plan:  Focus  on  backlog  definition  and  estimation  before  commencing  
work,  to  ensure  accurate  scope  definition.  
c.   How  to  deliver:  Work  in  predefined,  and  agreed,  backlog  order.  
d.   How  to  measure:  Measure  how  many  stories  have  been  accepted  so  far,  
and  project  the  rate  of  acceptance  into  the  future  to  assess  possible  delivery  
dates.  
4.   Fixed  cost  and  time:  This  is  equivalent  to  capped  time  &  materials.  Where  your  
customer  asks  for  a  fixed  price  quote,  with  final  delivery  due  by  a  specified  date.  In  
this  situation,  the  exact  set  of  features,  or  scope,  is  flexible.  
a.   For  example:  Work  on  an  agreed  product  until  the  end  of  the  financial  year.  
b.   How  to  quote  and  estimate:  Calculate  total  cost  as  cost  per  week,  or  cost  
per  iteration  –  this  is  one  of  the  simplest  types  of  quotations  and  fully  
compatible  with  #NoEstimates  because  you  are  pricing  the  project  based  on  
what  the  customer  expects  and  is  willing  to  pay,  and  not  on  the  potential  
estimated  cost.  The  cost  is  effectively  budgeted,  instead  of  estimated.  
c.   How  to  deliver:  In  addition  to  the  criteria  in  fixed  time  and  fixed  cost;;  update  
the  backlog  as  required.  
d.   How  to  measure:  Measure  how  many  stories  have  been  accepted  so  far,  
and  project  the  rate  of  acceptance  into  the  future  to  assess  how  many  stories  
can  be  delivered  in  the  available  time.  Measure  the  burn-­rate  to  ensure  that  
the  costs  are  in  line  with  the  expected  budget.  
5.   Fixed  cost  and  scope:  Where  your  customer  asks  for  a  fixed  price  quote,  for  a  pre-­
defined  set  of  requirements.  In  this  situation,  the  final  date  for  delivery  is  flexible.  
a.   For  example:  Build  and  deliver  a  product  to  architectural  specifications.  
b.   How  to  quote  and  plan:  Increase  the  contingency  (%  or  $)  during  iteration  0  
to  ensure  your  quote  allows  for  unexpected  delays  that  would  affect  your  cost  
to  deliver.  
c.   How  to  deliver:  In  addition  to  the  criteria  in  fixed  cost  and  fixed  scope;;  adjust  
the  delivery  date  as  required.  
d.   How  to  measure:  Measure  how  many  stories  have  been  accepted  so  far,  
and  project  the  rate  of  acceptance  into  the  future  to  assess  the  possible  
delivery  date  for  all  the  accepted  stories.  Measure  the  burn-­rate  to  ensure  that  
the  costs  are  in  line  with  the  expected  budget.  
6.   Fixed  time  and  scope:  Where  your  customer  asks  for  a  fixed  set  of  requirements,  
with  final  delivery  due  by  a  specified  date.  In  this  situation,  the  total  cost  to  the  
customer  is  flexible.  
a.   For  example:  Fulfilling  legal  requirements  prior  to  the  legal  cut-­off  date.  
b.   How  to  estimate  and  plan:  During  iteration  0,  pre-­assign  requirements  by  
week  or  iteration  to  define  the  scope  delivery  timetable.  Pad  the  schedule  with  
extra  time,  to  cater  for  unexpected  defects,  or  technical  debt.  
c.   How  to  deliver:  In  addition  to  the  criteria  in  fixed  time  and  fixed  scope;;  
increase  the  team  size  to  ensure  the  scope  is  completed  on  time.  
d.   How  to  measure:  Measure  how  many  stories  have  been  accepted  so  far,  
and  project  the  rate  of  acceptance  into  the  future  to  assess  the  possible  
delivery  date  for  all  the  accepted  stories.  Measure  the  burn-­rate  and  keep  the  
customer  informed  of  the  likely  final  cost  of  the  project.  
7.   Fixed  cost,  time  and  scope:  In  this  final  scenario,  your  customer  gives  you  no  
flexibility  in  the  project  budget,  schedule,  or  scope.  
 a.   Cancel  the  work.  This  is  not  suitable  for  agile,  and  should  be  run  using  a  
traditional  framework.  Even  then  it  is  likely  to  fail  without  some  flexibility.  
b.   but…  if  you  start  with  a  time  and  materials  pilot,  you  are  able  to  significantly  
mitigate  the  risk  associated  with  a  later  fully  fixed  contract.  

Internal funding models

So  far  we’ve  covered  how  to  create  an  agile  contract  in  the  context  of  two  separate  
organisations.  But  how  do  you  structure  a  funding  model  if  the  work  is  being  undertaken  
internally.  Most  finance  divisions  require  business  as  usual  (BAU)  budgets  and  project  
budgets  at  least  18  months  ahead.  This  can  make  it  difficult  to  react  or  proact  (if  it’s  not  a  
word,  it  should  be)  to  opportunities  in  the  market  -­  especially  in  a  #NoEstimates  context.  
However,  like  developing  agile  contracts,  there  are  options  available  to  you.    
 
While  this  is  a  topic  for  another  essay,  I  want  to  introduce  two  simple  approaches  you  can  
use  to  ensure  organisations  remain  adaptable.  These  are  a  team-­level  contingency  and  
rolling  monthly  (or  quarterly)  budgets.    

Team-level contingency
As  part  of  their  monthly  budget,  allocate  each  team  a  contingency  budget  (usually  ~20%)  to  
spend  at  their  discretion,  either  in  the  delivery  of  requirements,  or  as  a  mechanism  to  
innovate  change  within  the  organisation.  Unused  contingency  should  carry  over,  to  
encourage  sensible  spending,  rather  than  the  traditional  ‘use  it  or  lose  it’  approach.  

Monthly or quarterly budgets

By  reducing  the  duration  of  each  budget  period,  organisations  can  tailor  funding  to  meet  the  
current  needs  of  a  team,  or  department.  As  most  budget  proposals  will  be  identical,  or  nearly  
identical,  to  previous  months,  there  is  negligible  overhead  in  managing  multiple,  short,  
budgets.  Teams  and  departments  are  encouraged  (and  in  some  cases  incentivised)  to  be  
innovative  with  their  existing  budgets,  and,  where  possible,  reduce  outgoing  expenditure.  
This  requires  more  effort  from  the  finance  and  accounting  department,  but  is  manageable  
with  appropriate  tools  and  supporting  processes.    
 
There  are  still  issues  relating  to  capitalisation,  but  this  isn’t  a  new  problem.  Have  a  read  of  
the  Agile  Accounting  Standard  Program5  to  understand  how  agile  can  align  to  common  
accounting  standards.  

Conclusion
Fundamentally  all  these  approaches  come  down  to  core  principle  of  managing  risk.  Your  
contract  terms  are  going  to  be  set  by  the  level  of  risk  each  party  is  willing  to  accept.  In  an  
agile  or  #NoEstimates  context,  what  you  want  to  avoid  is  the  situation  where  a  contract  
overly  constrains  a  partnership  where  the  risk  is  already  low  or  can  be  accepted.    
 
Given  what  we  know  now,  let's  go  back  and  answer  the  original  three  questions.  
Q:  "How  much  is  this  going  to  cost?"  
A:  "As  much  as  you’re  willing  to  spend."  
 
                                                                                                     
5
 http://www.agilealliance.org/programs/agile-­accounting-­standard-­program/  
Q:  "How  long  is  this  going  to  take?"  
A:  "As  long  as  it  takes  to  deliver  what  you  ask."  
 
Q:  "What  am  I  going  to  get?"  
A:  "Whatever  you  tell  us  you  want."  
 
-­  Evan  Leybourn,  Singapore  
Blog:  http://theagiledirector.com  
Twitter:  @eleybourn  
LinkedIn:  http://au.linkedin.com/in/evanleybourn  
‘Directing  the  Agile  Organisation’  is  published  by  IT  Governance  Publishing  available  on  
Amazon,  at  Book  Depository,  and  all  good  bookshops.