57317Re: [scrumdevelopment] How to perform estimation for custom (billable) work
- Oct 18, 2013I 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.BestMarkus--Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
On 10.10.2013, at 22:24, <vilson_a@...> wrote:
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.
- << Previous post in topic Next post in topic >>