Re: [scrumdevelopment] SCRUM with Fixed Price Contracts
- Hello Ron and Group:
>>If the team is spending time with the customer, surely that should be billed. If the team is spending time planning and designing, surely that should be billed. Tell us more about how you account for your time?Historically, we have only billed developer time to the clients. The communication/ interaction/ project management time has not been billed. Analyst team time is billed however for all the solution framework work.
>> My favorite estimation technique is to put all the features on cards, have experienced team members estimate the cards as to how long they'd take to do in a perfect world, then multiply that number by three.And you provide these cards for the custom for an estimate of how much an iteration would cost the client?
>> So it's the manager / Scrum Master who is actually jerking the project around, not the customer?Its basically the client. Scrum Master just follows the brief - discusses with the client and then provides the milestone for modules completion.
>> It sounds to me as if that feedback loop, relating cost to value, is broken in your project. If that's the case, probably no estimation technique is going to help.I am not sure if I even understand what cost to value loop means. Probably Google around a bit. I am sure that business must generate profits and despite everything we are able to generate profits but probably not enough profits. We routinely offshoot our project estimates but probably because of other factors [low taxes, low salaries etc.] we are able to generate profits. And we all agree that there is scope for improvement.
>> I would like to hear more about the communication loop between team, manager, customer, as regards changes and costs.We have switched to using BaseCamp PMS over past one year or so. All project milestones, to-do lists, messages, documents are posted there. The team and client have access to this account where all project discussions are done.
The basic document which governs the discussion on changes and costs is the basic proposal document [specification and estimates].
Let's revisit our sign-in page functionality:
Ron Jeffries <ronjeffries@...> wrote:On Monday, July 3, 2006, at 4:41:03 AM, Vickydhiman wrote:
>>> Hi ... I was really wondering what you did /before/ you tried to go Agile, and how it had
>>> been working, and why you weren't able to do at least as well in an Agile situation as you did
>>> then. I'm not sure whether that's what you were addressing, but there's plenty of stuff to
>>> chat about:
> It was not working then - its not working now. In the past we used
> to have these discussions at the end of the project making us
> spend almost double the time on recoding. However, because the
> project was complete - the customer generally used to be
> reasonable [or should I say less demanding] in requests.
OK ... I'm missing something, not sure yet what ...
> Now - they are involved at each step and because nothing is built
> as yet they take their flights of imagination to seventh heavens.
> This ends up making us take longer to build but lesser to show in
> terms of time sheets [increased communication/ interaction -
> something which we have not historically kept track of]. But this
> is not the main problem. We are working on optimizing our
> interaction/ communication.
Below, you're talking about the manager doing most of the
communication with the real customer. So I'm not seeing what is
taking all this unallocated time. What am I missing?
If the team is spending time with the customer, surely that should
be billed. If the team is spending time planning and designing,
surely that should be billed. Tell us more about how you account for
> What concerns me is how to estimate correctly for a SCRUM project.
> If I did not have any existing estimation method - what would you
> recommend? Doing detailed CRC cards for all projects you are
> bidding for? Is it not a waste if you dont even get the project?
My answer would depend on what you did know. If you didn't know
anything, I'd not be suggesting being in the fixed-price contract
Bidding a project is always a waste if you don't get the project.
It's necessary to decide how much to spend on a bid. The less you
spend, the cheaper it is not to get the contract, and the riskier
your bid is. In general, Agile thinkers recommend against fixed
price projects. Of course, in general, everyone who does them wishes
they didn't have to. The reasons are the same.
I was thinking that your company, having done many projects, might
well have enough information to estimate projects very quickly. I'll
come back to that below.
My favorite estimation technique is to put all the features on
cards, have experienced team members estimate the cards as to how
long they'd take to do in a perfect world, then multiply that number
by three. (The number isn't entirely made up, it's based on my
experience, and a lot of other folks' experience, that it takes
between two and three times as long to do something in the real
world as a programmer thinks it would if everything went perfectly.)
BUT EVEN THEN ... you have to steer the project. That's discussed
below as well.
>>> OK, sounds good. I'm curious about a statistic. I've always
>>> suspected that projects like these have a roughly constant cost
>>> in $ / time per screen, or worst case $ / time per screen
>>> widget. Do you have enough data to address that fantasy of mine?
> Yes, we allot a weighted average - 75% to last one year and 25% to
> the previous years data. Is that sufficient?
I was asking, if you take your past projects and calculate their
cost per screen, how similar are the numbers from one project to
another? If those numbers vary too much, how similar are the costs
per screen widget?
I've had this thought that some simple calculation of number of
screens, perhaps times a complexity per screen factor, might
estimate project cost very well. Sounds like you might have enough
information to look into that, so I was wondering.
>>> Well, I'd think I'd go back to framing earlier if it's delaying
>>> things. I'd also wonder why the manager has much to do in the
>>> current sprint. Is manager also serving as Scrum Master, or ...
> Yes. He works as Scrum Master. Responsible for client
> communication [most of it], burn down chat updates.
>>>And who's the Product Owner? How do they interact with the
>>>process, with the customer, with the team?
> We do not have a Product Owner. I think the client would be the
> Product Owner in our case. SCRUM Master is in direct contact with
> the client from start of the project to end of the project.
So it's the manager / Scrum Master who is actually jerking the
project around, not the customer?
The Product Owner role is critical in Scrum. From the Product Owner
viewpoint, the team is a "machine" that produces features (backlog
items, stories) at a roughly fixed rate. To complete the project on
time and on budget, the Product Owner needs to pick the most
important features and defer the rest. It works best if the features
picked are made very simple at the beginning, then fancied up if
time and money permit.
In a situation such as yours, there would be a sketch, already
approved, I gather, of some simple screen. There would be a cost
associated with that screen. If the Product Owner wanted to make
that screen more complex, she would have to "pay" for it in time and
money, and if the budget were fixed, she'd have to give up something
else or pony up some more money.
It sounds to me as if that feedback loop, relating cost to value, is
broken in your project. If that's the case, probably no estimation
technique is going to help.
I would like to hear more about the communication loop between team,
manager, customer, as regards changes and costs.
Think! -- Aretha Franklin
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.
- On 5 Jul 2006, at 16:33, Vickydhiman wrote:
> Hello Sammy:[snip]
> Developers create the estimates based on specifications done by
> Analysts. For most cases, estimates already exists and are pulled
> from the database.
How accurate are the estimates pulled from the database? What happens
when they're wrong?
Who decides that the developer has met the analysts spec?