Loading ...
Sorry, an error occurred while loading the content.

57295Re: [scrumdevelopment] RE: How to perform estimation for custom (billable) work

Expand Messages
  • Adam Sroka
    Oct 16, 2013
    • 0 Attachment
      See comments inline: 


      On Wed, Oct 16, 2013 at 1:57 PM, <dutadoralin@...> wrote:
       

      Hi Alex,

      Using/under the following assumptions:

      1. the Dev Team worked previously together and they know what it brings them together (their strengths and weaknesses)

      2. the Dev Team worked previously with (a similar) technology

      3. per week, the Dev Team knows its Velocity for the best, worst and average case scenario (B,W,A)


      Even with all three, which arguably you can't expect to reliably find, there is still no guarantee that velocity on a new project will be similar or even stable early on. I have seen the same team working on similar technologies have radically different velocities on different projects and even during the course of the same project (e.g. as it grows in complexity and/or you start working on different feature sets) 
       

      4. there is a Product Backlog available and a Product Owner that can explain each Product Backlog Items


      You probably shouldn't expect to have this when you are selling the team to a prospective client. Identifying the PO is something you can do fairly early on, but developing a backlog for work you haven't even sold is waste (in the Lean sense) 
       

      5. the Scrum Team agrees and commits to an initial DoD that guarantees the Quality of the product/service that the project delivers 

      6. the Product Backlog (= Scope) remains unchanged during the project


      I wouldn't expect this either. In fact, there are a lot of companies out there who will sell fixed scope contracts for cheaper than you probably want to. I would tell them that I am running an Agile team, and that will cost you more, but it means that I will be responsive to scope changes. In other words, use the advantages of Scrum as a differentiator and be transparent about the attendant costs. 
       


      the Dev Team can come with a relatively good and realistic estimation in Time and $'s for the project as using the DoD and the known velocities (B,W,A) , the Dev Team forecasts the entire Product Backlog and they determine 

      a) the Total time (# weeks) that they need to accomplish the project in the best, worst and average case scenario

      b) the Total $'s = # weeks * 40 hours * SUM(hourly tariff per Dev Team member) 



      That's not quite right. You need to factor in other continuing costs such as facilities and equipment, etc. You also need to factor in project specific costs such as servers and materials (if any).  
    • Show all 17 messages in this topic