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

How to perform estimation for custom (billable) work

Expand Messages
  • vilson_a
    Hello everyone, I was wondering if you guys could help me out with this problem. Although I have worked in an Agile environment before, even as an Scrum
    Message 1 of 17 , Oct 10, 2013
    • 0 Attachment

      Hello everyone,

       

      I was wondering if you guys could help me out with this problem. Although I have worked in an Agile environment before, even as an Scrum Master, this is actually the first time I’m working in a company (currently implementing Agile) that does custom (billable) work.

      I am sure most of you have had the opportunity to deal with this situation, and I was wondering how you have worked it out.

       

      Estimation to price the “project” is currently done in hours, and of course it is a completely unrealistic number. Since I have been a Scrum master before, I am trying to help the Dev Manager figure this out.


      Just to clarify, for regular product roadmap items we do estimate in points (Fibonacci).

       

      Please let me know if any more detail is required.

       

      Thanks!

      Alex Pereira

      www.brainstack.net

       

       

       

    • Adam Sroka
      The best way to do it is optional scope. Deliver something every sprint. When your customer is happy with what you have delivered they can quit. You should
      Message 2 of 17 , Oct 16, 2013
      • 0 Attachment
        The best way to do it is optional scope. Deliver something every sprint. When your customer is happy with what you have delivered they can quit. You should know what it costs to run the team for a sprint. Add your margin to that and you know what you have to charge (To mitigate risk maybe negotiate for a minimum number of sprints and/or add additional margin to cover downtime between projects.) 

        If you need to calculate how many sprints it will take to complete some quantity of work, and you haven't had time to establish a velocity yet, the most realistic way to accomplish that is to look at how long it took you to develop products in the past. Come up with a range based on past performance and assume that it will take similar effort this time. 

        That may seem like an oversimplification, but it has the advantage of being based on something you know. It blows my mind that people think a bunch of small guesses added together are somehow more efficacious than one big guess. At least with the big guess you still have your eye on the ball and aren't bogged down in minutiae. 


        On Thu, Oct 10, 2013 at 4:24 PM, <vilson_a@...> wrote:
         

        Hello everyone,

         

        I was wondering if you guys could help me out with this problem. Although I have worked in an Agile environment before, even as an Scrum Master, this is actually the first time I’m working in a company (currently implementing Agile) that does custom (billable) work.

        I am sure most of you have had the opportunity to deal with this situation, and I was wondering how you have worked it out.

         

        Estimation to price the “project” is currently done in hours, and of course it is a completely unrealistic number. Since I have been a Scrum master before, I am trying to help the Dev Manager figure this out.


        Just to clarify, for regular product roadmap items we do estimate in points (Fibonacci).

         

        Please let me know if any more detail is required.

         

        Thanks!

        Alex Pereira

        www.brainstack.net

         

         

         


      • Vikrama Dhiman
        Hi Alex: I wrote about it several years ago. I think some if not all is still relevant. Here are some thumb rules (first 2 are sort of preachy - so skip to 4th
        Message 3 of 17 , Oct 16, 2013
        • 0 Attachment
          Hi Alex:

          I wrote about it several years ago. I think some if not all is still relevant. Here are some thumb rules (first 2 are sort of preachy - so skip to 4th for direct points);

          1. If you do want to do fixed price, you want to do it for less scope and not more (as it minimizes the risk).
          2. There is some literature on 1/3rd - 2/3rd contracts and some very little one on PS2000 contracts - dig into those.
          3. What starts as a custom fixed price billable project does not need to be so eventually too. You can easily convert a fixed-price to a more manageable time and material provided you show evidence of collaboration and business value delivery early on. So, get the project in how-so-ever you do it right now and then hopefully convert it later.
          4. Here is another technique which I have seen people use - float a RFP similar to work you would do and get 3-4 quotes yourself under a pseudo-name or something. Give you an idea of how much you should 'actually' bill. You could bill more if you have good presales team, domain expertise, proven record. 


          Good luck.

          -Vikrama Dhiman



          From: Adam Sroka <adam.sroka@...>
          To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
          Sent: Wednesday, October 16, 2013 8:07 PM
          Subject: Re: [scrumdevelopment] How to perform estimation for custom (billable) work

           
          The best way to do it is optional scope. Deliver something every sprint. When your customer is happy with what you have delivered they can quit. You should know what it costs to run the team for a sprint. Add your margin to that and you know what you have to charge (To mitigate risk maybe negotiate for a minimum number of sprints and/or add additional margin to cover downtime between projects.) 

          If you need to calculate how many sprints it will take to complete some quantity of work, and you haven't had time to establish a velocity yet, the most realistic way to accomplish that is to look at how long it took you to develop products in the past. Come up with a range based on past performance and assume that it will take similar effort this time. 

          That may seem like an oversimplification, but it has the advantage of being based on something you know. It blows my mind that people think a bunch of small guesses added together are somehow more efficacious than one big guess. At least with the big guess you still have your eye on the ball and aren't bogged down in minutiae. 


          On Thu, Oct 10, 2013 at 4:24 PM, <vilson_a@...> wrote:
           
          Hello everyone,
           
          I was wondering if you guys could help me out with this problem. Although I have worked in an Agile environment before, even as an Scrum Master, this is actually the first time I’m working in a company (currently implementing Agile) that does custom (billable) work.
          I am sure most of you have had the opportunity to deal with this situation, and I was wondering how you have worked it out.
           
          Estimation to price the “project” is currently done in hours, and of course it is a completely unrealistic number. Since I have been a Scrum master before, I am trying to help the Dev Manager figure this out.

          Just to clarify, for regular product roadmap items we do estimate in points (Fibonacci).
           
          Please let me know if any more detail is required.
           
          Thanks!
          Alex Pereira
           
           
           



        • Adam Sroka
          Excellent advice. I would add that even if you do decide to do fixed price/scope still run it iteratively and get frequent feedback. That way you don t head
          Message 4 of 17 , Oct 16, 2013
          • 0 Attachment
            Excellent advice.

            I would add that even if you do decide to do fixed price/scope still run it iteratively and get frequent feedback. That way you don't head down the wrong path. Also, if you are running late it's not a surprise and you can negotiate changes early. 

            Vet your customers carefully to make sure that they can provide the inputs and frequent feedback needed to run a successful Agile team. Don't chase bad money. The reputation of your team is more valuable than the revenue from a doomed project. 


            On Wed, Oct 16, 2013 at 10:53 AM, Vikrama Dhiman <vickydhiman@...> wrote:
             

            Hi Alex:

            I wrote about it several years ago. I think some if not all is still relevant. Here are some thumb rules (first 2 are sort of preachy - so skip to 4th for direct points);

            1. If you do want to do fixed price, you want to do it for less scope and not more (as it minimizes the risk).
            2. There is some literature on 1/3rd - 2/3rd contracts and some very little one on PS2000 contracts - dig into those.
            3. What starts as a custom fixed price billable project does not need to be so eventually too. You can easily convert a fixed-price to a more manageable time and material provided you show evidence of collaboration and business value delivery early on. So, get the project in how-so-ever you do it right now and then hopefully convert it later.
            4. Here is another technique which I have seen people use - float a RFP similar to work you would do and get 3-4 quotes yourself under a pseudo-name or something. Give you an idea of how much you should 'actually' bill. You could bill more if you have good presales team, domain expertise, proven record. 


            Good luck.

            -Vikrama Dhiman



            From: Adam Sroka <adam.sroka@...>
            To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
            Sent: Wednesday, October 16, 2013 8:07 PM
            Subject: Re: [scrumdevelopment] How to perform estimation for custom (billable) work

             
            The best way to do it is optional scope. Deliver something every sprint. When your customer is happy with what you have delivered they can quit. You should know what it costs to run the team for a sprint. Add your margin to that and you know what you have to charge (To mitigate risk maybe negotiate for a minimum number of sprints and/or add additional margin to cover downtime between projects.) 

            If you need to calculate how many sprints it will take to complete some quantity of work, and you haven't had time to establish a velocity yet, the most realistic way to accomplish that is to look at how long it took you to develop products in the past. Come up with a range based on past performance and assume that it will take similar effort this time. 

            That may seem like an oversimplification, but it has the advantage of being based on something you know. It blows my mind that people think a bunch of small guesses added together are somehow more efficacious than one big guess. At least with the big guess you still have your eye on the ball and aren't bogged down in minutiae. 


            On Thu, Oct 10, 2013 at 4:24 PM, <vilson_a@...> wrote:
             
            Hello everyone,
             
            I was wondering if you guys could help me out with this problem. Although I have worked in an Agile environment before, even as an Scrum Master, this is actually the first time I’m working in a company (currently implementing Agile) that does custom (billable) work.
            I am sure most of you have had the opportunity to deal with this situation, and I was wondering how you have worked it out.
             
            Estimation to price the “project” is currently done in hours, and of course it is a completely unrealistic number. Since I have been a Scrum master before, I am trying to help the Dev Manager figure this out.

            Just to clarify, for regular product roadmap items we do estimate in points (Fibonacci).
             
            Please let me know if any more detail is required.
             
            Thanks!
            Alex Pereira
             
             
             




          • vilson_a
            Thanks for all the replies so far. I guess I should add a little more context to my original post. We currently have 3 teams, and all teams work on a mix of
            Message 5 of 17 , Oct 16, 2013
            • 0 Attachment

              Thanks for all the replies so far.

               

              I guess I should add a little more context to my original post.

              We currently have 3 teams, and all teams work on a mix of roadmap and custom (billable) work, when the custom work is needed/required to be done.

               

              To my original post, where I state “estimation to price the project is currently done in hours”, that part is done by Sales/Middle Management (most of the time based on similar projects done in the past), this is way before it gets to the development teams.


              Once a project gets assigned to a team, the team will break it down into user stories and estimate them using Fibonacci.

               

              To explain the process a little bit further:

              1. All the way up top, during the “contract” estimation, the VP and other managers, will set a delivery date, and to do that they usually calculate how many hours the project was estimated (contracted) at, and then, based on the number of dev hours available, etc… give the client a fixed date.
              2. Once the project is estimated by the team (in points), and a release plan is done, they are realizing that the original (hours) estimate done by Management is not corresponding to the estimation (points) done by the Team, and then they are realizing that they over committed.

               

              Since Q4 was the first quarter they have ever been able to have everything estimated ahead of time, it was a big surprise for them to “see” (ahead of time – and not at the last 2 weeks) that they over-estimated, and the team will not be able to complete all work that was “promised” by management without some “creative planning”.

               

              One solution that is floating around is to have a separate team to do all custom work, and they would not estimate in points. Which I honestly think will not solve any problem.

               

              Thanks again!

              Alex Pereira

              www.brainstack.net

               

               



              ---In scrumdevelopment@yahoogroups.com, <adam.sroka@...> wrote:

              Excellent advice.

              I would add that even if you do decide to do fixed price/scope still run it iteratively and get frequent feedback. That way you don't head down the wrong path. Also, if you are running late it's not a surprise and you can negotiate changes early. 

              Vet your customers carefully to make sure that they can provide the inputs and frequent feedback needed to run a successful Agile team. Don't chase bad money. The reputation of your team is more valuable than the revenue from a doomed project. 


              On Wed, Oct 16, 2013 at 10:53 AM, Vikrama Dhiman <vickydhiman@...> wrote:
               
              Hi Alex:

              I wrote about it several years ago. I think some if not all is still relevant. Here are some thumb rules (first 2 are sort of preachy - so skip to 4th for direct points);

              1. If you do want to do fixed price, you want to do it for less scope and not more (as it minimizes the risk).
              2. There is some literature on 1/3rd - 2/3rd contracts and some very little one on PS2000 contracts - dig into those.
              3. What starts as a custom fixed price billable project does not need to be so eventually too. You can easily convert a fixed-price to a more manageable time and material provided you show evidence of collaboration and business value delivery early on. So, get the project in how-so-ever you do it right now and then hopefully convert it later.
              4. Here is another technique which I have seen people use - float a RFP similar to work you would do and get 3-4 quotes yourself under a pseudo-name or something. Give you an idea of how much you should 'actually' bill. You could bill more if you have good presales team, domain expertise, proven record. 


              Good luck.

              -Vikrama Dhiman



              From: Adam Sroka <adam.sroka@...>
              To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
              Sent: Wednesday, October 16, 2013 8:07 PM
              Subject: Re: [scrumdevelopment] How to perform estimation for custom (billable) work

               
              The best way to do it is optional scope. Deliver something every sprint. When your customer is happy with what you have delivered they can quit. You should know what it costs to run the team for a sprint. Add your margin to that and you know what you have to charge (To mitigate risk maybe negotiate for a minimum number of sprints and/or add additional margin to cover downtime between projects.) 

              If you need to calculate how many sprints it will take to complete some quantity of work, and you haven't had time to establish a velocity yet, the most realistic way to accomplish that is to look at how long it took you to develop products in the past. Come up with a range based on past performance and assume that it will take similar effort this time. 

              That may seem like an oversimplification, but it has the advantage of being based on something you know. It blows my mind that people think a bunch of small guesses added together are somehow more efficacious than one big guess. At least with the big guess you still have your eye on the ball and aren't bogged down in minutiae. 


              On Thu, Oct 10, 2013 at 4:24 PM, <vilson_a@...> wrote:
               
              Hello everyone,
               
              I was wondering if you guys could help me out with this problem. Although I have worked in an Agile environment before, even as an Scrum Master, this is actually the first time I’m working in a company (currently implementing Agile) that does custom (billable) work.
              I am sure most of you have had the opportunity to deal with this situation, and I was wondering how you have worked it out.
               
              Estimation to price the “project” is currently done in hours, and of course it is a completely unrealistic number. Since I have been a Scrum master before, I am trying to help the Dev Manager figure this out.

              Just to clarify, for regular product roadmap items we do estimate in points (Fibonacci).
               
              Please let me know if any more detail is required.
               
              Thanks!
              Alex Pereira
               
               
               




            • Markus Gärtner
              Hi Alex, yes, more details are required. Best Markus -- Dipl.-Inform. Markus Gärtner Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven
              Message 6 of 17 , Oct 16, 2013
              • 0 Attachment
                Hi Alex,

                yes, more details are required.

                Best
                Markus

                --
                Dipl.-Inform. Markus Gärtner
                Author of ATDD by Example - A Practical Guide to Acceptance
                Test-Driven Development

                On 10.10.2013, at 22:24, <vilson_a@...> wrote:

                Hello everyone,

                 

                I was wondering if you guys could help me out with this problem. Although I have worked in an Agile environment before, even as an Scrum Master, this is actually the first time I’m working in a company (currently implementing Agile) that does custom (billable) work.

                I am sure most of you have had the opportunity to deal with this situation, and I was wondering how you have worked it out.

                 

                Estimation to price the “project” is currently done in hours, and of course it is a completely unrealistic number. Since I have been a Scrum master before, I am trying to help the Dev Manager figure this out.


                Just to clarify, for regular product roadmap items we do estimate in points (Fibonacci).

                 

                Please let me know if any more detail is required.

                 

                Thanks!

                Alex Pereira

                www.brainstack.net

                 

                 

                 

              • Cass Dalton
                I work for a defense contractor and we have been struggling with similar issues. It is a common problem in the contracting world and in software estimation in
                Message 7 of 17 , Oct 16, 2013
                • 0 Attachment
                  I work for a defense contractor and we have been struggling with similar issues.  It is a common problem in the contracting world and in software estimation in general.  Any cool, fun, billable software development is complex.  Developers have a tendency to underestimate the work because they think of the work optimistically and don't often account for things going wrong (especially when they haven't been held accountable for their own estimates).  Program managers have a tendency to underestimate because they want to win new work.  If my company bids $1 million and your company bids $1.5 million for effectively the same capability, they're going to give me the contract.  Even if it takes me $1.5 million dollars to execute, I got the work and I got my foot in the door and I can weave stories about how the extra $500k was "out of scope" of the original requirements.  However, this is an unsustainable business practice.

                  Enter Agile.  One of the things that draws me to agile is the work breakdown.  The work is divided into tiny pieces and worked off and that reduces how much effect Murphy can have on your project.  When he does show up, he has a more limited impact.  That doesn't change the fact that you're still going to under bid, but it does allow you to proactively adjust scope to fit your new understanding of the project and its budget and schedule.  What does help the estimation is to dive into more detail about the project BEFORE you bid it.  Using planning poker at an iteration planning session is a form of the delphi (http://en.wikipedia.org/wiki/Delphi_method) estimation technique.  When you utilize those same concepts in the planning and proposal stages of an effort you will get much better and more realistic estimate.

                  You need to understand if your dev manager just doesn't understand that the estimates are unrealistic, or if he doesn't WANT to know that they are unrealistic because he wants to bid a low number.


                  On Wed, Oct 16, 2013 at 12:51 PM, Markus Gärtner <mgaertne@...> wrote:
                   

                  Hi Alex,

                  yes, more details are required.

                  Best
                  Markus

                  --
                  Dipl.-Inform. Markus Gärtner
                  Author of ATDD by Example - A Practical Guide to Acceptance
                  Test-Driven Development

                  On 10.10.2013, at 22:24, <vilson_a@...> wrote:

                  Hello everyone,

                   

                  I was wondering if you guys could help me out with this problem. Although I have worked in an Agile environment before, even as an Scrum Master, this is actually the first time I’m working in a company (currently implementing Agile) that does custom (billable) work.

                  I am sure most of you have had the opportunity to deal with this situation, and I was wondering how you have worked it out.

                   

                  Estimation to price the “project” is currently done in hours, and of course it is a completely unrealistic number. Since I have been a Scrum master before, I am trying to help the Dev Manager figure this out.


                  Just to clarify, for regular product roadmap items we do estimate in points (Fibonacci).

                   

                  Please let me know if any more detail is required.

                   

                  Thanks!

                  Alex Pereira

                  www.brainstack.net

                   

                   

                   


                • dutadoralin
                  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
                  Message 8 of 17 , Oct 16, 2013
                  • 0 Attachment

                    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)

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

                    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


                    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) 




                    ---In scrumdevelopment@yahoogroups.com, <vilson_a@...> wrote:

                    Hello everyone,

                     

                    I was wondering if you guys could help me out with this problem. Although I have worked in an Agile environment before, even as an Scrum Master, this is actually the first time I’m working in a company (currently implementing Agile) that does custom (billable) work.

                    I am sure most of you have had the opportunity to deal with this situation, and I was wondering how you have worked it out.

                     

                    Estimation to price the “project” is currently done in hours, and of course it is a completely unrealistic number. Since I have been a Scrum master before, I am trying to help the Dev Manager figure this out.


                    Just to clarify, for regular product roadmap items we do estimate in points (Fibonacci).

                     

                    Please let me know if any more detail is required.

                     

                    Thanks!

                    Alex Pereira

                    www.brainstack.net

                     

                     

                     

                  • Adam Sroka
                    See comments inline: ... 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
                    Message 9 of 17 , 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).  
                    • Michael Vizdos
                      The good thing about Scrum is that it exposes the dysfunctional habits of an organization. They are there with or without Scrum. If you figure out a silver
                      Message 10 of 17 , Oct 18, 2013
                      • 0 Attachment

                        The good thing about Scrum is that it exposes the dysfunctional habits of an organization. They are there with or without Scrum.

                        If you figure out a silver Bullet then you will become a rich individual.

                        All estimates are wrong.  They are estimates. 

                        Perhaps a good thing to try to iterate with at this point is a discussion with your sales teams and middle and upper management about this topic. 

                        Your team must decide what works best for you.  Then go and out compete in your market. 

                        The info here is good in this thread. 

                        Best thing is #deliver and start some real conversations about this within the organization.

                        If you are given a time and a budget and scope in which all three are fixed perhaps you should consider not using agile techniques because fixing all three is not a sustainable model. 

                        Good luck with this.  If you'd like to have a conversation about this (email is not a high fidelity way to discuss this topic) please feel free to reach out to me and we can chat or skype or have a quick call. 

                        Thank you.

                        Mike Vizdos
                        www.michaelvizdos.com/contact

                        On Oct 17, 2013 7:35 PM, <vilson_a@...> wrote:
                         

                        Thanks for all the replies so far.

                         

                        I guess I should add a little more context to my original post.

                        We currently have 3 teams, and all teams work on a mix of roadmap and custom (billable) work, when the custom work is needed/required to be done.

                         

                        To my original post, where I state “estimation to price the project is currently done in hours”, that part is done by Sales/Middle Management (most of the time based on similar projects done in the past), this is way before it gets to the development teams.


                        Once a project gets assigned to a team, the team will break it down into user stories and estimate them using Fibonacci.

                         

                        To explain the process a little bit further:

                        1. All the way up top, during the “contract” estimation, the VP and other managers, will set a delivery date, and to do that they usually calculate how many hours the project was estimated (contracted) at, and then, based on the number of dev hours available, etc… give the client a fixed date.
                        2. Once the project is estimated by the team (in points), and a release plan is done, they are realizing that the original (hours) estimate done by Management is not corresponding to the estimation (points) done by the Team, and then they are realizing that they over committed.

                         

                        Since Q4 was the first quarter they have ever been able to have everything estimated ahead of time, it was a big surprise for them to “see” (ahead of time – and not at the last 2 weeks) that they over-estimated, and the team will not be able to complete all work that was “promised” by management without some “creative planning”.

                         

                        One solution that is floating around is to have a separate team to do all custom work, and they would not estimate in points. Which I honestly think will not solve any problem.

                         

                        Thanks again!

                        Alex Pereira

                        www.brainstack.net

                         

                         



                        ---In scrumdevelopment@yahoogroups.com, <adam.sroka@...> wrote:

                        Excellent advice.

                        I would add that even if you do decide to do fixed price/scope still run it iteratively and get frequent feedback. That way you don't head down the wrong path. Also, if you are running late it's not a surprise and you can negotiate changes early. 

                        Vet your customers carefully to make sure that they can provide the inputs and frequent feedback needed to run a successful Agile team. Don't chase bad money. The reputation of your team is more valuable than the revenue from a doomed project. 


                        On Wed, Oct 16, 2013 at 10:53 AM, Vikrama Dhiman <vickydhiman@...> wrote:
                         
                        Hi Alex:

                        I wrote about it several years ago. I think some if not all is still relevant. Here are some thumb rules (first 2 are sort of preachy - so skip to 4th for direct points);

                        1. If you do want to do fixed price, you want to do it for less scope and not more (as it minimizes the risk).
                        2. There is some literature on 1/3rd - 2/3rd contracts and some very little one on PS2000 contracts - dig into those.
                        3. What starts as a custom fixed price billable project does not need to be so eventually too. You can easily convert a fixed-price to a more manageable time and material provided you show evidence of collaboration and business value delivery early on. So, get the project in how-so-ever you do it right now and then hopefully convert it later.
                        4. Here is another technique which I have seen people use - float a RFP similar to work you would do and get 3-4 quotes yourself under a pseudo-name or something. Give you an idea of how much you should 'actually' bill. You could bill more if you have good presales team, domain expertise, proven record. 


                        Good luck.

                        -Vikrama Dhiman



                        From: Adam Sroka <adam.sroka@...>
                        To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                        Sent: Wednesday, October 16, 2013 8:07 PM
                        Subject: Re: [scrumdevelopment] How to perform estimation for custom (billable) work

                         
                        The best way to do it is optional scope. Deliver something every sprint. When your customer is happy with what you have delivered they can quit. You should know what it costs to run the team for a sprint. Add your margin to that and you know what you have to charge (To mitigate risk maybe negotiate for a minimum number of sprints and/or add additional margin to cover downtime between projects.) 

                        If you need to calculate how many sprints it will take to complete some quantity of work, and you haven't had time to establish a velocity yet, the most realistic way to accomplish that is to look at how long it took you to develop products in the past. Come up with a range based on past performance and assume that it will take similar effort this time. 

                        That may seem like an oversimplification, but it has the advantage of being based on something you know. It blows my mind that people think a bunch of small guesses added together are somehow more efficacious than one big guess. At least with the big guess you still have your eye on the ball and aren't bogged down in minutiae. 


                        On Thu, Oct 10, 2013 at 4:24 PM, <vilson_a@...> wrote:
                         
                        Hello everyone,
                         
                        I was wondering if you guys could help me out with this problem. Although I have worked in an Agile environment before, even as an Scrum Master, this is actually the first time I’m working in a company (currently implementing Agile) that does custom (billable) work.
                        I am sure most of you have had the opportunity to deal with this situation, and I was wondering how you have worked it out.
                         
                        Estimation to price the “project” is currently done in hours, and of course it is a completely unrealistic number. Since I have been a Scrum master before, I am trying to help the Dev Manager figure this out.

                        Just to clarify, for regular product roadmap items we do estimate in points (Fibonacci).
                         
                        Please let me know if any more detail is required.
                         
                        Thanks!
                        Alex Pereira
                         
                         
                         




                      • Kurt Häusler
                        Hi Alex, I have written a blog post about this topic and have given a talk at a conference about it: Blog post:
                        Message 11 of 17 , Oct 18, 2013
                        • 0 Attachment
                          Hi Alex,

                          I have written a blog post about this topic and have given a talk at a
                          conference about it:

                          Blog post: http://kurthaeusler.wordpress.com/2013/05/20/pricing-and-a-little-bit-about-estimation/
                          Conference talk video: http://www.youtube.com/watch?v=NgOnS1scD24
                          Conference talk slides: http://www.slideshare.net/kurthaeusler/offers-andpricing

                          The theoretical best is value based pricing, or basing the price on
                          the value that the customer will get from the software, but it might
                          be hard for a software development service provider to work with for
                          various reasons. The customer might not know or be willing to share
                          the value. Or even if we discover a value, we still have to make sure
                          our costs are covered.

                          My current favorite is price per (in Scrum terms) PBI. Simply divide
                          the teams total costs for the past 12 months by the number of PBIs
                          they have delivered to work out your costs per PBI. Add a small margin
                          and there is your price per PBI.

                          However in my recent experience customers have their favorite pitch
                          and purchase procedures and allow little flexibility. For example 95%
                          of the customers I have worked with recently ask for an hourly rate,
                          and the number of hours the development will take. The web page that
                          you (or the person in the purchasing department you talk to on the
                          phone) asks for that information, there is no slot for doing anything
                          else. In a sense this makes things easier as it takes the issue of the
                          table.

                          Since you are asking the question, am I right in assuming the customer
                          actually allows you some flexibility in how you come up with a price?
                          If that is the case, then you are very lucky. You actually have a good
                          chance to get things started right, without the disadvantages of the
                          old t&m and fixed price models that we seem to have automatically
                          carried over to the agile world without thinking about it.

                          If you don't get this flexibility, then the answer is depressingly
                          simple. Just do it however the customer permits or understands.

                          May I ask, what industry you (or your customers) are in?

                          On Thu, Oct 10, 2013 at 10:24 PM, <vilson_a@...> wrote:
                          >
                          >
                          > Hello everyone,
                          >
                          >
                          >
                          > I was wondering if you guys could help me out with this problem. Although I
                          > have worked in an Agile environment before, even as an Scrum Master, this is
                          > actually the first time I’m working in a company (currently implementing
                          > Agile) that does custom (billable) work.
                          >
                          > I am sure most of you have had the opportunity to deal with this situation,
                          > and I was wondering how you have worked it out.
                          >
                          >
                          >
                          > Estimation to price the “project” is currently done in hours, and of course
                          > it is a completely unrealistic number. Since I have been a Scrum master
                          > before, I am trying to help the Dev Manager figure this out.
                          >
                          >
                          > Just to clarify, for regular product roadmap items we do estimate in points
                          > (Fibonacci).
                          >
                          >
                          >
                          > Please let me know if any more detail is required.
                          >
                          >
                          >
                          > Thanks!
                          >
                          > Alex Pereira
                          >
                          > www.brainstack.net
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                        • Kurt Häusler
                          Yep your current process is dripping with dysfunction. But assuming your customers, sales, middle management and VP recognize that, and are open to
                          Message 12 of 17 , Oct 18, 2013
                          • 0 Attachment
                            Yep your current process is dripping with dysfunction.

                            But assuming your customers, sales, middle management and VP recognize
                            that, and are open to alternatives then the battle is practically won!
                            The ideas are out there, it is just that they hardly ever get used
                            because things kind of fall apart at the convincing others that there
                            is even a problem bit.

                            Try the price per PBI model and see how it goes.

                            On Wed, Oct 16, 2013 at 5:17 PM, <vilson_a@...> wrote:
                            >
                            >
                            > Thanks for all the replies so far.
                            >
                            >
                            >
                            > I guess I should add a little more context to my original post.
                            >
                            > We currently have 3 teams, and all teams work on a mix of roadmap and custom
                            > (billable) work, when the custom work is needed/required to be done.
                            >
                            >
                            >
                            > To my original post, where I state “estimation to price the project is
                            > currently done in hours”, that part is done by Sales/Middle Management (most
                            > of the time based on similar projects done in the past), this is way before
                            > it gets to the development teams.
                            >
                            >
                            > Once a project gets assigned to a team, the team will break it down into
                            > user stories and estimate them using Fibonacci.
                            >
                            >
                            >
                            > To explain the process a little bit further:
                            >
                            > All the way up top, during the “contract” estimation, the VP and other
                            > managers, will set a delivery date, and to do that they usually calculate
                            > how many hours the project was estimated (contracted) at, and then, based on
                            > the number of dev hours available, etc… give the client a fixed date.
                            > Once the project is estimated by the team (in points), and a release plan is
                            > done, they are realizing that the original (hours) estimate done by
                            > Management is not corresponding to the estimation (points) done by the Team,
                            > and then they are realizing that they over committed.
                            >
                            >
                            >
                            > Since Q4 was the first quarter they have ever been able to have everything
                            > estimated ahead of time, it was a big surprise for them to “see” (ahead of
                            > time – and not at the last 2 weeks) that they over-estimated, and the team
                            > will not be able to complete all work that was “promised” by management
                            > without some “creative planning”.
                            >
                            >
                            >
                            > One solution that is floating around is to have a separate team to do all
                            > custom work, and they would not estimate in points. Which I honestly think
                            > will not solve any problem.
                            >
                            >
                            >
                            > Thanks again!
                            >
                            > Alex Pereira
                            >
                            > www.brainstack.net
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            > ---In scrumdevelopment@yahoogroups.com, <adam.sroka@...> wrote:
                            >
                            > Excellent advice.
                            >
                            > I would add that even if you do decide to do fixed price/scope still run it
                            > iteratively and get frequent feedback. That way you don't head down the
                            > wrong path. Also, if you are running late it's not a surprise and you can
                            > negotiate changes early.
                            >
                            > Vet your customers carefully to make sure that they can provide the inputs
                            > and frequent feedback needed to run a successful Agile team. Don't chase bad
                            > money. The reputation of your team is more valuable than the revenue from a
                            > doomed project.
                            >
                            >
                            > On Wed, Oct 16, 2013 at 10:53 AM, Vikrama Dhiman <vickydhiman@...> wrote:
                            >
                            >
                            > Hi Alex:
                            >
                            > I wrote about it several years ago. I think some if not all is still
                            > relevant. Here are some thumb rules (first 2 are sort of preachy - so skip
                            > to 4th for direct points);
                            >
                            > 1. If you do want to do fixed price, you want to do it for less scope and
                            > not more (as it minimizes the risk).
                            > 2. There is some literature on 1/3rd - 2/3rd contracts and some very little
                            > one on PS2000 contracts - dig into those.
                            > 3. What starts as a custom fixed price billable project does not need to be
                            > so eventually too. You can easily convert a fixed-price to a more manageable
                            > time and material provided you show evidence of collaboration and business
                            > value delivery early on. So, get the project in how-so-ever you do it right
                            > now and then hopefully convert it later.
                            > 4. Here is another technique which I have seen people use - float a RFP
                            > similar to work you would do and get 3-4 quotes yourself under a pseudo-name
                            > or something. Give you an idea of how much you should 'actually' bill. You
                            > could bill more if you have good presales team, domain expertise, proven
                            > record.
                            >
                            > Check more at http://agilediary.wordpress.com/category/contracts/
                            >
                            > Good luck.
                            >
                            > -Vikrama Dhiman
                            >
                            >
                            > ________________________________
                            > From: Adam Sroka <adam.sroka@...>
                            >
                            > To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                            > Sent: Wednesday, October 16, 2013 8:07 PM
                            > Subject: Re: [scrumdevelopment] How to perform estimation for custom
                            > (billable) work
                            >
                            >
                            > The best way to do it is optional scope. Deliver something every sprint.
                            > When your customer is happy with what you have delivered they can quit. You
                            > should know what it costs to run the team for a sprint. Add your margin to
                            > that and you know what you have to charge (To mitigate risk maybe negotiate
                            > for a minimum number of sprints and/or add additional margin to cover
                            > downtime between projects.)
                            >
                            > If you need to calculate how many sprints it will take to complete some
                            > quantity of work, and you haven't had time to establish a velocity yet, the
                            > most realistic way to accomplish that is to look at how long it took you to
                            > develop products in the past. Come up with a range based on past performance
                            > and assume that it will take similar effort this time.
                            >
                            > That may seem like an oversimplification, but it has the advantage of being
                            > based on something you know. It blows my mind that people think a bunch of
                            > small guesses added together are somehow more efficacious than one big
                            > guess. At least with the big guess you still have your eye on the ball and
                            > aren't bogged down in minutiae.
                            >
                            >
                            > On Thu, Oct 10, 2013 at 4:24 PM, <vilson_a@...> wrote:
                            >
                            >
                            > Hello everyone,
                            >
                            > I was wondering if you guys could help me out with this problem. Although I
                            > have worked in an Agile environment before, even as an Scrum Master, this is
                            > actually the first time I’m working in a company (currently implementing
                            > Agile) that does custom (billable) work.
                            > I am sure most of you have had the opportunity to deal with this situation,
                            > and I was wondering how you have worked it out.
                            >
                            > Estimation to price the “project” is currently done in hours, and of course
                            > it is a completely unrealistic number. Since I have been a Scrum master
                            > before, I am trying to help the Dev Manager figure this out.
                            >
                            > Just to clarify, for regular product roadmap items we do estimate in points
                            > (Fibonacci).
                            >
                            > Please let me know if any more detail is required.
                            >
                            > Thanks!
                            > Alex Pereira
                            > www.brainstack.net
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                          • Yves Hanoulle
                            I understand: You need to understand if your dev manager just doesn t understand that the estimates are unrealistic, or if he doesn t WANT to know that they
                            Message 13 of 17 , Oct 18, 2013
                            • 0 Attachment
                              I understand: "You need to understand if your dev manager just doesn't understand that the estimates are unrealistic, or if he doesn't WANT to know that they are unrealistic because he wants to bid a low number."

                              for me, if they want estimates with the idea to underbid, I will still give them te best estimates I can (even if that is limited) and then "they" (whoever they are) can decide how much to underbid. it's their job to deal with the bidding and the risks of that, not the developers.

                              yet I think it's stupid as every client will at on time understand that the person who understands least of the problem will get the job.
                              That is bringing their project in risk.

                              yet that dysfunction has already been stated enough here.

                              my focus is: the rest of your company is dysfunctional, ok, most companies have dysfunctions . we try to visualize them and protect us from that...


                               


                              2013/10/16 Cass Dalton <cassdalton73@...>
                               

                              I work for a defense contractor and we have been struggling with similar issues.  It is a common problem in the contracting world and in software estimation in general.  Any cool, fun, billable software development is complex.  Developers have a tendency to underestimate the work because they think of the work optimistically and don't often account for things going wrong (especially when they haven't been held accountable for their own estimates).  Program managers have a tendency to underestimate because they want to win new work.  If my company bids $1 million and your company bids $1.5 million for effectively the same capability, they're going to give me the contract.  Even if it takes me $1.5 million dollars to execute, I got the work and I got my foot in the door and I can weave stories about how the extra $500k was "out of scope" of the original requirements.  However, this is an unsustainable business practice.

                              Enter Agile.  One of the things that draws me to agile is the work breakdown.  The work is divided into tiny pieces and worked off and that reduces how much effect Murphy can have on your project.  When he does show up, he has a more limited impact.  That doesn't change the fact that you're still going to under bid, but it does allow you to proactively adjust scope to fit your new understanding of the project and its budget and schedule.  What does help the estimation is to dive into more detail about the project BEFORE you bid it.  Using planning poker at an iteration planning session is a form of the delphi (http://en.wikipedia.org/wiki/Delphi_method) estimation technique.  When you utilize those same concepts in the planning and proposal stages of an effort you will get much better and more realistic estimate.

                              You need to understand if your dev manager just doesn't understand that the estimates are unrealistic, or if he doesn't WANT to know that they are unrealistic because he wants to bid a low number.


                              On Wed, Oct 16, 2013 at 12:51 PM, Markus Gärtner <mgaertne@...> wrote:
                               

                              Hi Alex,

                              yes, more details are required.

                              Best
                              Markus

                              --
                              Dipl.-Inform. Markus Gärtner
                              Author of ATDD by Example - A Practical Guide to Acceptance
                              Test-Driven Development

                              On 10.10.2013, at 22:24, <vilson_a@...> wrote:

                              Hello everyone,

                               

                              I was wondering if you guys could help me out with this problem. Although I have worked in an Agile environment before, even as an Scrum Master, this is actually the first time I’m working in a company (currently implementing Agile) that does custom (billable) work.

                              I am sure most of you have had the opportunity to deal with this situation, and I was wondering how you have worked it out.

                               

                              Estimation to price the “project” is currently done in hours, and of course it is a completely unrealistic number. Since I have been a Scrum master before, I am trying to help the Dev Manager figure this out.


                              Just to clarify, for regular product roadmap items we do estimate in points (Fibonacci).

                               

                              Please let me know if any more detail is required.

                               

                              Thanks!

                              Alex Pereira

                              www.brainstack.net

                               

                               

                               



                            • vilson_a
                              Hi Guys, I am sorry for the delay in my responses. Since I am new, I am moderated, and it is taking a while for my messages to go through. Thanks a lot for all
                              Message 14 of 17 , Oct 18, 2013
                              • 0 Attachment

                                 Hi Guys,

                                 

                                I am sorry for the delay in my responses. Since I am new, I am moderated, and it is taking a while for my messages to go through.

                                 

                                Thanks a lot for all your replies. I will go into all provided links and will report back if any clarification is required. I wanted to send this e-mail right away for acknowledgment of your responses, and to add some more clarification on my side.

                                 

                                My company creates software to help the management of projects and also financials within the construction industry. Most of the custom work comes from 3rd party integration, like SalesForce, etc. Also, keep in mind that the majority of the custom work is for current clients. Although I am sure that we quote it for prospect clients as well.

                                 

                                I am hearing a lot of good things as far as strategies to bill for custom work, and maybe I led you guys in that direction.  However, what we are trying to figure out is the process of how to best account for custom work when planning a release, for example. I think that figuring out the billing part, should come after.

                                 

                                Based on our current process:

                                 

                                Let’s say, the VP of Development and other managers decided that our department can produce 9000 hours of work in a quarter (20 days * 8 * 3  * about 20 devs –  (minus) some buffer) (I am imagining their calculation is pretty close to this) between all 3 teams. So, they start looking at the work (custom and roadmap) estimated (high-level in hours), and start to schedule them within those 9000 hours , until they get 0 hours left. So, if for instance 2000 hours of custom was “sold” to clients, they will fill out the rest (7000 hour) with roadmap items.

                                 

                                After the teams are assigned the work (epic level) they start breaking them down into user stories and then estimate them. Then, they do a release planning to figure out how to slot all those user stories. At this point they are realizing that N hours (from the original high level estimation) per team, cannot be slotted - The managers over committed them.

                                 

                                One idea I had was to have the teams estimate the work on a high level first – before a quote is giving to clients. Maybe breaking the work enough so that we can use S/M/L sizes with fixed points for each size.  I don’t know maybe S=13, M=20 and L=40. And then, after the high level estimates are done, management can then convert those points into hours (using past velocity) and “bill” or at least match the now estimated work to the original 9000 hours based on that.

                                 

                                For example: Let’s say that custom work was estimated by the dev team to have 5 small (5 *13), 2 medium (2 * 20) and 3 large (3 * 40). This would equate to 225 points. Let’s that based on past data, the team’s point/hour is 1/8. So, 225 points * 8 hours would be equal to 1800 hours.

                                 

                                They would use 1800 hours as the number of billable hours.  And at a high level, we would use 225 points from our total capacity for the release.

                                 

                                Is this something that we could do? Are there any other alternative? Or should I just tell them, “if you’re going to use hours, we better not use Scrum”?

                                 

                                I hope I have expressed the problem clear enough.

                                 

                                Thanks again!

                                Alex Pereiera

                                www.brainstack.net

                                 

                                 

                                 

                                 

                                 

                                 

                                 

                                 

                                 

                                 



                                ---In scrumdevelopment@yahoogroups.com, <kurt.haeusler@...> wrote:

                                Yep your current process is dripping with dysfunction.

                                But assuming your customers, sales, middle management and VP recognize
                                that, and are open to alternatives then the battle is practically won!
                                The ideas are out there, it is just that they hardly ever get used
                                because things kind of fall apart at the convincing others that there
                                is even a problem bit.

                                Try the price per PBI model and see how it goes.

                                On Wed, Oct 16, 2013 at 5:17 PM, <vilson_a@...> wrote:
                                >
                                >
                                > Thanks for all the replies so far.
                                >
                                >
                                >
                                > I guess I should add a little more context to my original post.
                                >
                                > We currently have 3 teams, and all teams work on a mix of roadmap and custom
                                > (billable) work, when the custom work is needed/required to be done.
                                >
                                >
                                >
                                > To my original post, where I state “estimation to price the project is
                                > currently done in hours”, that part is done by Sales/Middle Management (most
                                > of the time based on similar projects done in the past), this is way before
                                > it gets to the development teams.
                                >
                                >
                                > Once a project gets assigned to a team, the team will break it down into
                                > user stories and estimate them using Fibonacci.
                                >
                                >
                                >
                                > To explain the process a little bit further:
                                >
                                > All the way up top, during the “contract” estimation, the VP and other
                                > managers, will set a delivery date, and to do that they usually calculate
                                > how many hours the project was estimated (contracted) at, and then, based on
                                > the number of dev hours available, etc… give the client a fixed date.
                                > Once the project is estimated by the team (in points), and a release plan is
                                > done, they are realizing that the original (hours) estimate done by
                                > Management is not corresponding to the estimation (points) done by the Team,
                                > and then they are realizing that they over committed.
                                >
                                >
                                >
                                > Since Q4 was the first quarter they have ever been able to have everything
                                > estimated ahead of time, it was a big surprise for them to “see” (ahead of
                                > time – and not at the last 2 weeks) that they over-estimated, and the team
                                > will not be able to complete all work that was “promised” by management
                                > without some “creative planning”.
                                >
                                >
                                >
                                > One solution that is floating around is to have a separate team to do all
                                > custom work, and they would not estimate in points. Which I honestly think
                                > will not solve any problem.
                                >
                                >
                                >
                                > Thanks again!
                                >
                                > Alex Pereira
                                >
                                > www.brainstack.net
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                                > ---In scrumdevelopment@yahoogroups.com, <adam.sroka@...> wrote:
                                >
                                > Excellent advice.
                                >
                                > I would add that even if you do decide to do fixed price/scope still run it
                                > iteratively and get frequent feedback. That way you don't head down the
                                > wrong path. Also, if you are running late it's not a surprise and you can
                                > negotiate changes early.
                                >
                                > Vet your customers carefully to make sure that they can provide the inputs
                                > and frequent feedback needed to run a successful Agile team. Don't chase bad
                                > money. The reputation of your team is more valuable than the revenue from a
                                > doomed project.
                                >
                                >
                                > On Wed, Oct 16, 2013 at 10:53 AM, Vikrama Dhiman <vickydhiman@...> wrote:
                                >
                                >
                                > Hi Alex:
                                >
                                > I wrote about it several years ago. I think some if not all is still
                                > relevant. Here are some thumb rules (first 2 are sort of preachy - so skip
                                > to 4th for direct points);
                                >
                                > 1. If you do want to do fixed price, you want to do it for less scope and
                                > not more (as it minimizes the risk).
                                > 2. There is some literature on 1/3rd - 2/3rd contracts and some very little
                                > one on PS2000 contracts - dig into those.
                                > 3. What starts as a custom fixed price billable project does not need to be
                                > so eventually too. You can easily convert a fixed-price to a more manageable
                                > time and material provided you show evidence of collaboration and business
                                > value delivery early on. So, get the project in how-so-ever you do it right
                                > now and then hopefully convert it later.
                                > 4. Here is another technique which I have seen people use - float a RFP
                                > similar to work you would do and get 3-4 quotes yourself under a pseudo-name
                                > or something. Give you an idea of how much you should 'actually' bill. You
                                > could bill more if you have good presales team, domain expertise, proven
                                > record.
                                >
                                > Check more at http://agilediary.wordpress.com/category/contracts/
                                >
                                > Good luck.
                                >
                                > -Vikrama Dhiman
                                >
                                >
                                > ________________________________
                                > From: Adam Sroka <adam.sroka@...>
                                >
                                > To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                                > Sent: Wednesday, October 16, 2013 8:07 PM
                                > Subject: Re: [scrumdevelopment] How to perform estimation for custom
                                > (billable) work
                                >
                                >
                                > The best way to do it is optional scope. Deliver something every sprint.
                                > When your customer is happy with what you have delivered they can quit. You
                                > should know what it costs to run the team for a sprint. Add your margin to
                                > that and you know what you have to charge (To mitigate risk maybe negotiate
                                > for a minimum number of sprints and/or add additional margin to cover
                                > downtime between projects.)
                                >
                                > If you need to calculate how many sprints it will take to complete some
                                > quantity of work, and you haven't had time to establish a velocity yet, the
                                > most realistic way to accomplish that is to look at how long it took you to
                                > develop products in the past. Come up with a range based on past performance
                                > and assume that it will take similar effort this time.
                                >
                                > That may seem like an oversimplification, but it has the advantage of being
                                > based on something you know. It blows my mind that people think a bunch of
                                > small guesses added together are somehow more efficacious than one big
                                > guess. At least with the big guess you still have your eye on the ball and
                                > aren't bogged down in minutiae.
                                >
                                >
                                > On Thu, Oct 10, 2013 at 4:24 PM, <vilson_a@...> wrote:
                                >
                                >
                                > Hello everyone,
                                >
                                > I was wondering if you guys could help me out with this problem. Although I
                                > have worked in an Agile environment before, even as an Scrum Master, this is
                                > actually the first time I’m working in a company (currently implementing
                                > Agile) that does custom (billable) work.
                                > I am sure most of you have had the opportunity to deal with this situation,
                                > and I was wondering how you have worked it out.
                                >
                                > Estimation to price the “project” is currently done in hours, and of course
                                > it is a completely unrealistic number. Since I have been a Scrum master
                                > before, I am trying to help the Dev Manager figure this out.
                                >
                                > Just to clarify, for regular product roadmap items we do estimate in points
                                > (Fibonacci).
                                >
                                > Please let me know if any more detail is required.
                                >
                                > Thanks!
                                > Alex Pereira
                                > www.brainstack.net
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                              • vilson_a
                                Hi Guys, I am sorry for the delay in my responses. Since I am new, I am moderated, and it is taking a while for my messages to go through. Thanks a lot for all
                                Message 15 of 17 , Oct 18, 2013
                                • 0 Attachment

                                  Hi Guys,

                                   

                                  I am sorry for the delay in my responses. Since I am new, I am moderated, and it is taking a while for my messages to go through.

                                   

                                  Thanks a lot for all your replies. I will go into all provided links and will report back if any clarification is required. I wanted to send this e-mail right away for acknowledgment of your responses, and to add some more clarification on my side.

                                   

                                  My company creates software to help the management of projects and also financials within the construction industry. Most of the custom work comes from 3rd party integration, like SalesForce, etc. Also, keep in mind that the majority of the custom work is for current clients. Although I am sure that we quote it for prospect clients as well.

                                   

                                  I am hearing a lot of good things as far as strategies to bill for custom work, and maybe I led you guys in that direction.  However, what we are trying to figure out is the process of how to best account for custom work when planning a release, for example. I think that figuring out the billing part, should come after.

                                   

                                  Based on our current process:

                                   

                                  Let’s say, the VP of Development and other managers decided that our department can produce 9000 hours of work in a quarter (20 days * 8 * 3  * about 20 devs –  (minus) some buffer) (I am imagining their calculation is pretty close to this) between all 3 teams. So, they start looking at the work (custom and roadmap) estimated (high-level in hours), and start to schedule them within those 9000 hours , until they get 0 hours left. So, if for instance 2000 hours of custom was “sold” to clients, they will fill out the rest (7000 hour) with roadmap items.

                                   

                                  After the teams are assigned the work (epic level) they start breaking them down into user stories and then estimate them. Then, they do a release planning to figure out how to slot all those user stories. At this point they are realizing that N hours (from the original high level estimation) per team, cannot be slotted - The managers over committed them.

                                   

                                  One idea I had was to have the teams estimate the work on a high level first – before a quote is giving to clients. Maybe breaking the work enough so that we can use S/M/L sizes with fixed points for each size.  I don’t know maybe S=13, M=20 and L=40. And then, after the high level estimates are done, management can then convert those points into hours (using past velocity) and “bill” or at least match the now estimated work to the original 9000 hours based on that.

                                   

                                  For example: Let’s say that custom work was estimated by the dev team to have 5 small (5 *13), 2 medium (2 * 20) and 3 large (3 * 40). This would equate to 225 points. Let’s that based on past data, the team’s point/hour is 1/8. So, 225 points * 8 hours would be equal to 1800 hours.

                                   

                                  They would use 1800 hours as the number of billable hours.  And at a high level, we would use 225 points from hour total capacity for the release.

                                   

                                  Is this something that we could do? Are there any other alternative? Or should I just tell them, “if you’re going to use ours, we better not use Scrum”?

                                   

                                  I hope I have expressed the problem clear enough.

                                   

                                  Thanks again!

                                  Alex Pereiera

                                  www.brainstack.net

                                   

                                   

                                   

                                   

                                   

                                   

                                   

                                   

                                   

                                    



                                  ---In scrumdevelopment@yahoogroups.com, <kurt.haeusler@...> wrote:

                                  Yep your current process is dripping with dysfunction.

                                  But assuming your customers, sales, middle management and VP recognize
                                  that, and are open to alternatives then the battle is practically won!
                                  The ideas are out there, it is just that they hardly ever get used
                                  because things kind of fall apart at the convincing others that there
                                  is even a problem bit.

                                  Try the price per PBI model and see how it goes.

                                  On Wed, Oct 16, 2013 at 5:17 PM, <vilson_a@...> wrote:
                                  >
                                  >
                                  > Thanks for all the replies so far.
                                  >
                                  >
                                  >
                                  > I guess I should add a little more context to my original post.
                                  >
                                  > We currently have 3 teams, and all teams work on a mix of roadmap and custom
                                  > (billable) work, when the custom work is needed/required to be done.
                                  >
                                  >
                                  >
                                  > To my original post, where I state “estimation to price the project is
                                  > currently done in hours”, that part is done by Sales/Middle Management (most
                                  > of the time based on similar projects done in the past), this is way before
                                  > it gets to the development teams.
                                  >
                                  >
                                  > Once a project gets assigned to a team, the team will break it down into
                                  > user stories and estimate them using Fibonacci.
                                  >
                                  >
                                  >
                                  > To explain the process a little bit further:
                                  >
                                  > All the way up top, during the “contract” estimation, the VP and other
                                  > managers, will set a delivery date, and to do that they usually calculate
                                  > how many hours the project was estimated (contracted) at, and then, based on
                                  > the number of dev hours available, etc… give the client a fixed date.
                                  > Once the project is estimated by the team (in points), and a release plan is
                                  > done, they are realizing that the original (hours) estimate done by
                                  > Management is not corresponding to the estimation (points) done by the Team,
                                  > and then they are realizing that they over committed.
                                  >
                                  >
                                  >
                                  > Since Q4 was the first quarter they have ever been able to have everything
                                  > estimated ahead of time, it was a big surprise for them to “see” (ahead of
                                  > time – and not at the last 2 weeks) that they over-estimated, and the team
                                  > will not be able to complete all work that was “promised” by management
                                  > without some “creative planning”.
                                  >
                                  >
                                  >
                                  > One solution that is floating around is to have a separate team to do all
                                  > custom work, and they would not estimate in points. Which I honestly think
                                  > will not solve any problem.
                                  >
                                  >
                                  >
                                  > Thanks again!
                                  >
                                  > Alex Pereira
                                  >
                                  > www.brainstack.net
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  > ---In scrumdevelopment@yahoogroups.com, <adam.sroka@...> wrote:
                                  >
                                  > Excellent advice.
                                  >
                                  > I would add that even if you do decide to do fixed price/scope still run it
                                  > iteratively and get frequent feedback. That way you don't head down the
                                  > wrong path. Also, if you are running late it's not a surprise and you can
                                  > negotiate changes early.
                                  >
                                  > Vet your customers carefully to make sure that they can provide the inputs
                                  > and frequent feedback needed to run a successful Agile team. Don't chase bad
                                  > money. The reputation of your team is more valuable than the revenue from a
                                  > doomed project.
                                  >
                                  >
                                  > On Wed, Oct 16, 2013 at 10:53 AM, Vikrama Dhiman <vickydhiman@...> wrote:
                                  >
                                  >
                                  > Hi Alex:
                                  >
                                  > I wrote about it several years ago. I think some if not all is still
                                  > relevant. Here are some thumb rules (first 2 are sort of preachy - so skip
                                  > to 4th for direct points);
                                  >
                                  > 1. If you do want to do fixed price, you want to do it for less scope and
                                  > not more (as it minimizes the risk).
                                  > 2. There is some literature on 1/3rd - 2/3rd contracts and some very little
                                  > one on PS2000 contracts - dig into those.
                                  > 3. What starts as a custom fixed price billable project does not need to be
                                  > so eventually too. You can easily convert a fixed-price to a more manageable
                                  > time and material provided you show evidence of collaboration and business
                                  > value delivery early on. So, get the project in how-so-ever you do it right
                                  > now and then hopefully convert it later.
                                  > 4. Here is another technique which I have seen people use - float a RFP
                                  > similar to work you would do and get 3-4 quotes yourself under a pseudo-name
                                  > or something. Give you an idea of how much you should 'actually' bill. You
                                  > could bill more if you have good presales team, domain expertise, proven
                                  > record.
                                  >
                                  > Check more at http://agilediary.wordpress.com/category/contracts/
                                  >
                                  > Good luck.
                                  >
                                  > -Vikrama Dhiman
                                  >
                                  >
                                  > ________________________________
                                  > From: Adam Sroka <adam.sroka@...>
                                  >
                                  > To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                                  > Sent: Wednesday, October 16, 2013 8:07 PM
                                  > Subject: Re: [scrumdevelopment] How to perform estimation for custom
                                  > (billable) work
                                  >
                                  >
                                  > The best way to do it is optional scope. Deliver something every sprint.
                                  > When your customer is happy with what you have delivered they can quit. You
                                  > should know what it costs to run the team for a sprint. Add your margin to
                                  > that and you know what you have to charge (To mitigate risk maybe negotiate
                                  > for a minimum number of sprints and/or add additional margin to cover
                                  > downtime between projects.)
                                  >
                                  > If you need to calculate how many sprints it will take to complete some
                                  > quantity of work, and you haven't had time to establish a velocity yet, the
                                  > most realistic way to accomplish that is to look at how long it took you to
                                  > develop products in the past. Come up with a range based on past performance
                                  > and assume that it will take similar effort this time.
                                  >
                                  > That may seem like an oversimplification, but it has the advantage of being
                                  > based on something you know. It blows my mind that people think a bunch of
                                  > small guesses added together are somehow more efficacious than one big
                                  > guess. At least with the big guess you still have your eye on the ball and
                                  > aren't bogged down in minutiae.
                                  >
                                  >
                                  > On Thu, Oct 10, 2013 at 4:24 PM, <vilson_a@...> wrote:
                                  >
                                  >
                                  > Hello everyone,
                                  >
                                  > I was wondering if you guys could help me out with this problem. Although I
                                  > have worked in an Agile environment before, even as an Scrum Master, this is
                                  > actually the first time I’m working in a company (currently implementing
                                  > Agile) that does custom (billable) work.
                                  > I am sure most of you have had the opportunity to deal with this situation,
                                  > and I was wondering how you have worked it out.
                                  >
                                  > Estimation to price the “project” is currently done in hours, and of course
                                  > it is a completely unrealistic number. Since I have been a Scrum master
                                  > before, I am trying to help the Dev Manager figure this out.
                                  >
                                  > Just to clarify, for regular product roadmap items we do estimate in points
                                  > (Fibonacci).
                                  >
                                  > Please let me know if any more detail is required.
                                  >
                                  > Thanks!
                                  > Alex Pereira
                                  > www.brainstack.net
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                • Kurt Häusler
                                  Hi, I will put my comments inline: ... So if I understand you correctly, it is about balancing capacity between two sources of demand. (Not sure how sensible
                                  Message 16 of 17 , Oct 21, 2013
                                  • 0 Attachment
                                    Hi,

                                    I will put my comments inline:

                                    On Fri, Oct 18, 2013 at 2:57 PM, <vilson_a@...> wrote:

                                    > I am hearing a lot of good things as far as strategies to bill for custom
                                    > work, and maybe I led you guys in that direction. However, what we are
                                    > trying to figure out is the process of how to best account for custom work
                                    > when planning a release, for example. I think that figuring out the billing
                                    > part, should come after.
                                    >

                                    So if I understand you correctly, it is about balancing capacity
                                    between two sources of demand. (Not sure how sensible it is to leave
                                    billing as an afterthought though).

                                    >
                                    > Let’s say, the VP of Development and other managers decided that our
                                    > department can produce 9000 hours of work in a quarter (20 days * 8 * 3 *
                                    > about 20 devs – (minus) some buffer) (I am imagining their calculation is
                                    > pretty close to this) between all 3 teams. So, they start looking at the
                                    > work (custom and roadmap) estimated (high-level in hours), and start to
                                    > schedule them within those 9000 hours , until they get 0 hours left. So, if
                                    > for instance 2000 hours of custom was “sold” to clients, they will fill out
                                    > the rest (7000 hour) with roadmap items.

                                    There are a lot of reasons why I don't like this approach so much. The
                                    main one is a bit abstract, but "hours of work" is an input. It is not
                                    what the team produces, it is what the team invests in order to get
                                    what the team produces: software features.

                                    Am I correct in assuming the custom billable work should be priced in
                                    order to fund the roadmap items?

                                    How you bill is actually important. If you do some sort of fixed price
                                    thing, then you might "spend" 2000 hours, but only deliver 1800 hours
                                    worth of what the customer expects. The customer can still get what
                                    they want, because you have 7000 more hours in the quarter to spend
                                    working on the features that weren't completed in the 2000. However if
                                    you haven't priced it appropriately, the money earned from the 1800
                                    hours worth of work you delivered might not be enough to cover the
                                    roadmap items in the way you calculated. If you are doing high-value,
                                    high-margin work it shouldn't be a problem, but if you are doing
                                    competitive commodity work in a saturated market you might have tight
                                    margins and eat them up. However with other pricing models, you could
                                    spend more time on custom work, bill more, and simply end up getting
                                    less roadmap items done as intended, which might not be a huge deal.



                                    >
                                    > After the teams are assigned the work (epic level) they start breaking them
                                    > down into user stories and then estimate them. Then, they do a release
                                    > planning to figure out how to slot all those user stories. At this point
                                    > they are realizing that N hours (from the original high level estimation)
                                    > per team, cannot be slotted - The managers over committed them.

                                    If this is at the beginning, before any sprints, and you don't have
                                    any velocity then you are just comparing two fantasies with each
                                    other. How do you know the manager got it right, and the team is under
                                    committing? Do a sprint, get an actual measure of the capability, and
                                    update the release plan. Repeat.


                                    >
                                    > One idea I had was to have the teams estimate the work on a high level first
                                    > – before a quote is giving to clients. Maybe breaking the work enough so
                                    > that we can use S/M/L sizes with fixed points for each size. I don’t know
                                    > maybe S=13, M=20 and L=40. And then, after the high level estimates are
                                    > done, management can then convert those points into hours (using past
                                    > velocity) and “bill” or at least match the now estimated work to the
                                    > original 9000 hours based on that.

                                    Why (or how) would one convert from point estimates to hours and then
                                    to money? You could skip the hours bit, and convert directly from
                                    points to money for example. Is your velocity something like "hours of
                                    work delivered" based on the hour estimates? For me that has a lot of
                                    downsides. You end up with managers wondering why the team only
                                    delivered 45 hours of work, when there were 100 developer hours
                                    available.

                                    >
                                    > For example: Let’s say that custom work was estimated by the dev team to
                                    > have 5 small (5 *13), 2 medium (2 * 20) and 3 large (3 * 40). This would
                                    > equate to 225 points. Let’s that based on past data, the team’s point/hour
                                    > is 1/8. So, 225 points * 8 hours would be equal to 1800 hours.
                                    >
                                    >
                                    >
                                    > They would use 1800 hours as the number of billable hours. And at a high
                                    > level, we would use 225 points from our total capacity for the release.
                                    >

                                    Hmm might be better than time tracking I guess, but you run the risk
                                    of under-charging. You have to know that 1800 billable hours will be
                                    expected to cover 3000 actual hours.

                                    >
                                    > Is this something that we could do? Are there any other alternative? Or
                                    > should I just tell them, “if you’re going to use hours, we better not use
                                    > Scrum”?
                                    >

                                    Yeah I find billable hours to be fundamentally rotten, and very hard
                                    to work with. It gives rise to lots of dysfunction. If you have to use
                                    them, you can still work with scrum, but you might need to come up
                                    with creative ideas for fixing the dysfunction they introduce.

                                    >
                                    > I hope I have expressed the problem clear enough.

                                    Well sort of, first you say its not about billing it is about
                                    balancing capacity across two demand sources, then the rest of your
                                    post kind of talks about billing again.

                                    I would make it a lot simpler. Your managers want 22% of capacity
                                    allocated to custom work, and 78% to roadmap items.

                                    If the three teams together can deliver 500 PBIs per quarter and cost
                                    500,000 per quarter then your internal cost per PBI is 1000.

                                    In each quarter we want to therefore deliver 110 custom items, and 390
                                    roadmap items.

                                    Assuming custom work is supposed to fund roadmap items, then that
                                    means 110 items have to altogether cost at least 500,000. Or roughly
                                    4600 per item.

                                    Then, you need to look at your backlogs, and make sure that roughly
                                    22% of the items are custom work, and 78% of the items are roadmap.
                                    Same with sprint planning. In each sprint, if the velocity is 10
                                    items, then plan 2 custom items and 8 roadmap items. Not every team
                                    needs to stick to this exact division, it is ok for one team to do
                                    mostly roadmap and another team to do mostly custom, but overall, in
                                    average, the whole system should allocate 22% of its capacity to
                                    custom and 78% to roadmap.

                                    This figures need to be regularly updated according to your
                                    measurements. Every month look at the numbers, and see if everything
                                    adds up. You are actually quite lucky to have so much roadmap work
                                    funded by relatively fewer custom items. If things start to get too
                                    expensive for the customer you can just allocate more capacity to
                                    custom, and accept a lower throughput rate of roadmap items.

                                    Anyway, I would really try and keep "hours" out of the calculations
                                    (and where hours are really needed, just do a last minute conversion
                                    for those special cases). Things like story points and t-shirt sizes I
                                    would consider optional. Use them if they help, but it is possible to
                                    do these sorts of calculations with just a count of PBIs.

                                    Hope this helps,

                                    Kurt
                                  • Michael Vizdos
                                    Hi. Sounds over complicated. Have you asked the team how they would handle it? There are many red flags in your response so my recommendation is to ask the
                                    Message 17 of 17 , Oct 22, 2013
                                    • 0 Attachment

                                      Hi.

                                      Sounds over complicated. 

                                      Have you asked the team how they would handle it?

                                      There are many red flags in your response so my recommendation is to ask the team perhaps as a retrospective topic one day.

                                      The team may already know a simple answer. Sometimes simple works.  Real life is messy.  Work with the people on the team delivering to help solve this perceived problem.  

                                      Good luck and let me know if you'd like to have a conversation sometime.

                                      Thank you.

                                      Mike Vizdos
                                      www.michaelvizdos.com/contact

                                      On Oct 21, 2013 6:50 AM, <vilson_a@...> wrote:
                                       

                                       Hi Guys,

                                       

                                      I am sorry for the delay in my responses. Since I am new, I am moderated, and it is taking a while for my messages to go through.

                                       

                                      Thanks a lot for all your replies. I will go into all provided links and will report back if any clarification is required. I wanted to send this e-mail right away for acknowledgment of your responses, and to add some more clarification on my side.

                                       

                                      My company creates software to help the management of projects and also financials within the construction industry. Most of the custom work comes from 3rd party integration, like SalesForce, etc. Also, keep in mind that the majority of the custom work is for current clients. Although I am sure that we quote it for prospect clients as well.

                                       

                                      I am hearing a lot of good things as far as strategies to bill for custom work, and maybe I led you guys in that direction.  However, what we are trying to figure out is the process of how to best account for custom work when planning a release, for example. I think that figuring out the billing part, should come after.

                                       

                                      Based on our current process:

                                       

                                      Let’s say, the VP of Development and other managers decided that our department can produce 9000 hours of work in a quarter (20 days * 8 * 3  * about 20 devs –  (minus) some buffer) (I am imagining their calculation is pretty close to this) between all 3 teams. So, they start looking at the work (custom and roadmap) estimated (high-level in hours), and start to schedule them within those 9000 hours , until they get 0 hours left. So, if for instance 2000 hours of custom was “sold” to clients, they will fill out the rest (7000 hour) with roadmap items.

                                       

                                      After the teams are assigned the work (epic level) they start breaking them down into user stories and then estimate them. Then, they do a release planning to figure out how to slot all those user stories. At this point they are realizing that N hours (from the original high level estimation) per team, cannot be slotted - The managers over committed them.

                                       

                                      One idea I had was to have the teams estimate the work on a high level first – before a quote is giving to clients. Maybe breaking the work enough so that we can use S/M/L sizes with fixed points for each size.  I don’t know maybe S=13, M=20 and L=40. And then, after the high level estimates are done, management can then convert those points into hours (using past velocity) and “bill” or at least match the now estimated work to the original 9000 hours based on that.

                                       

                                      For example: Let’s say that custom work was estimated by the dev team to have 5 small (5 *13), 2 medium (2 * 20) and 3 large (3 * 40). This would equate to 225 points. Let’s that based on past data, the team’s point/hour is 1/8. So, 225 points * 8 hours would be equal to 1800 hours.

                                       

                                      They would use 1800 hours as the number of billable hours.  And at a high level, we would use 225 points from our total capacity for the release.

                                       

                                      Is this something that we could do? Are there any other alternative? Or should I just tell them, “if you’re going to use hours, we better not use Scrum”?

                                       

                                      I hope I have expressed the problem clear enough.

                                       

                                      Thanks again!

                                      Alex Pereiera

                                      www.brainstack.net

                                       

                                       

                                       

                                       

                                       

                                       

                                       

                                       

                                       

                                       



                                      ---In scrumdevelopment@yahoogroups.com, <kurt.haeusler@...> wrote:

                                      Yep your current process is dripping with dysfunction.

                                      But assuming your customers, sales, middle management and VP recognize
                                      that, and are open to alternatives then the battle is practically won!
                                      The ideas are out there, it is just that they hardly ever get used
                                      because things kind of fall apart at the convincing others that there
                                      is even a problem bit.

                                      Try the price per PBI model and see how it goes.

                                      On Wed, Oct 16, 2013 at 5:17 PM, <vilson_a@...> wrote:
                                      >
                                      >
                                      > Thanks for all the replies so far.
                                      >
                                      >
                                      >
                                      > I guess I should add a little more context to my original post.
                                      >
                                      > We currently have 3 teams, and all teams work on a mix of roadmap and custom
                                      > (billable) work, when the custom work is needed/required to be done.
                                      >
                                      >
                                      >
                                      > To my original post, where I state “estimation to price the project is
                                      > currently done in hours”, that part is done by Sales/Middle Management (most
                                      > of the time based on similar projects done in the past), this is way before
                                      > it gets to the development teams.
                                      >
                                      >
                                      > Once a project gets assigned to a team, the team will break it down into
                                      > user stories and estimate them using Fibonacci.
                                      >
                                      >
                                      >
                                      > To explain the process a little bit further:
                                      >
                                      > All the way up top, during the “contract” estimation, the VP and other
                                      > managers, will set a delivery date, and to do that they usually calculate
                                      > how many hours the project was estimated (contracted) at, and then, based on
                                      > the number of dev hours available, etc… give the client a fixed date.
                                      > Once the project is estimated by the team (in points), and a release plan is
                                      > done, they are realizing that the original (hours) estimate done by
                                      > Management is not corresponding to the estimation (points) done by the Team,
                                      > and then they are realizing that they over committed.
                                      >
                                      >
                                      >
                                      > Since Q4 was the first quarter they have ever been able to have everything
                                      > estimated ahead of time, it was a big surprise for them to “see” (ahead of
                                      > time – and not at the last 2 weeks) that they over-estimated, and the team
                                      > will not be able to complete all work that was “promised” by management
                                      > without some “creative planning”.
                                      >
                                      >
                                      >
                                      > One solution that is floating around is to have a separate team to do all
                                      > custom work, and they would not estimate in points. Which I honestly think
                                      > will not solve any problem.
                                      >
                                      >
                                      >
                                      > Thanks again!
                                      >
                                      > Alex Pereira
                                      >
                                      > www.brainstack.net
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      > ---In scrumdevelopment@yahoogroups.com, <adam.sroka@...> wrote:
                                      >
                                      > Excellent advice.
                                      >
                                      > I would add that even if you do decide to do fixed price/scope still run it
                                      > iteratively and get frequent feedback. That way you don't head down the
                                      > wrong path. Also, if you are running late it's not a surprise and you can
                                      > negotiate changes early.
                                      >
                                      > Vet your customers carefully to make sure that they can provide the inputs
                                      > and frequent feedback needed to run a successful Agile team. Don't chase bad
                                      > money. The reputation of your team is more valuable than the revenue from a
                                      > doomed project.
                                      >
                                      >
                                      > On Wed, Oct 16, 2013 at 10:53 AM, Vikrama Dhiman <vickydhiman@...> wrote:
                                      >
                                      >
                                      > Hi Alex:
                                      >
                                      > I wrote about it several years ago. I think some if not all is still
                                      > relevant. Here are some thumb rules (first 2 are sort of preachy - so skip
                                      > to 4th for direct points);
                                      >
                                      > 1. If you do want to do fixed price, you want to do it for less scope and
                                      > not more (as it minimizes the risk).
                                      > 2. There is some literature on 1/3rd - 2/3rd contracts and some very little
                                      > one on PS2000 contracts - dig into those.
                                      > 3. What starts as a custom fixed price billable project does not need to be
                                      > so eventually too. You can easily convert a fixed-price to a more manageable
                                      > time and material provided you show evidence of collaboration and business
                                      > value delivery early on. So, get the project in how-so-ever you do it right
                                      > now and then hopefully convert it later.
                                      > 4. Here is another technique which I have seen people use - float a RFP
                                      > similar to work you would do and get 3-4 quotes yourself under a pseudo-name
                                      > or something. Give you an idea of how much you should 'actually' bill. You
                                      > could bill more if you have good presales team, domain expertise, proven
                                      > record.
                                      >
                                      > Check more at http://agilediary.wordpress.com/category/contracts/
                                      >
                                      > Good luck.
                                      >
                                      > -Vikrama Dhiman
                                      >
                                      >
                                      > ________________________________
                                      > From: Adam Sroka <adam.sroka@...>
                                      >
                                      > To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                                      > Sent: Wednesday, October 16, 2013 8:07 PM
                                      > Subject: Re: [scrumdevelopment] How to perform estimation for custom
                                      > (billable) work
                                      >
                                      >
                                      > The best way to do it is optional scope. Deliver something every sprint.
                                      > When your customer is happy with what you have delivered they can quit. You
                                      > should know what it costs to run the team for a sprint. Add your margin to
                                      > that and you know what you have to charge (To mitigate risk maybe negotiate
                                      > for a minimum number of sprints and/or add additional margin to cover
                                      > downtime between projects.)
                                      >
                                      > If you need to calculate how many sprints it will take to complete some
                                      > quantity of work, and you haven't had time to establish a velocity yet, the
                                      > most realistic way to accomplish that is to look at how long it took you to
                                      > develop products in the past. Come up with a range based on past performance
                                      > and assume that it will take similar effort this time.
                                      >
                                      > That may seem like an oversimplification, but it has the advantage of being
                                      > based on something you know. It blows my mind that people think a bunch of
                                      > small guesses added together are somehow more efficacious than one big
                                      > guess. At least with the big guess you still have your eye on the ball and
                                      > aren't bogged down in minutiae.
                                      >
                                      >
                                      > On Thu, Oct 10, 2013 at 4:24 PM, <vilson_a@...> wrote:
                                      >
                                      >
                                      > Hello everyone,
                                      >
                                      > I was wondering if you guys could help me out with this problem. Although I
                                      > have worked in an Agile environment before, even as an Scrum Master, this is
                                      > actually the first time I’m working in a company (currently implementing
                                      > Agile) that does custom (billable) work.
                                      > I am sure most of you have had the opportunity to deal with this situation,
                                      > and I was wondering how you have worked it out.
                                      >
                                      > Estimation to price the “project” is currently done in hours, and of course
                                      > it is a completely unrealistic number. Since I have been a Scrum master
                                      > before, I am trying to help the Dev Manager figure this out.
                                      >
                                      > Just to clarify, for regular product roadmap items we do estimate in points
                                      > (Fibonacci).
                                      >
                                      > Please let me know if any more detail is required.
                                      >
                                      > Thanks!
                                      > Alex Pereira
                                      > www.brainstack.net
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                    Your message has been successfully submitted and would be delivered to recipients shortly.