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

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

Expand Messages
  • Michael Vizdos
    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
       
       
       




    • Show all 17 messages in this topic