Re: [scrumdevelopment] SCRUM with Fixed Price Contracts
>> 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.
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.
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?
>> 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?
>> 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.
Ron Jeffries <ronjeffries@...> wrote:On Saturday, July 1, 2006, at 12:05:12 PM, Vickydhiman wrote:
> Hello Ron [and Group] :)
> First of all, one of the reasons why I joined Agile was not only
> because we have trouble with our Hybird methods [mix of RUP +
> SCRUM - and no we don't call it SCRUM :) ]. First of all our
> organization deals with Web based projects only. What we generally
> do is define requirements up front in detail [at least till a
> level that goes through the reviews passed as detail enough]. We
> traditionally do it by explaining using a sample wireframe of the
> screen and how different set of users would be able to use the
> functionality on the wireframe. I guess it would be better to
> explain it with an example:
> I would draw a simple screen [using PowerPoint or some other
> simple too] with two text boxes [for user name and password]. I
> would also dig up my image library for sample submit buttons/
> reset buttons. I will place the links Register Now and Forgot
> Password. I will then explain function of buttons and links. I
> would also make it a point to mention that registration link goes
> to the registration wireframe [wireframe number would be
> provided]. In case of unsuccessful log in [exceptions] , the
> wireframe screen is also referenced. Similarly, ideal case is
OK ... I think I'd be inclined to do this with pen and paper, or my
Tablet, but to each ...
> Based on this, we would use our historical estimates [revised
> every month] for sign-in screen and add-up these estimates for all
> screens. In case, the estimate does not exist, the screen is shown
> to three senior "Technical Leads" [managers are not kept in loop
> during estimation]. Average estimate is taken for these screens.
> After all the estimates are added, the project is multiplied with
> a complexity factor and an analyst who has not been involved in
> estimation process would review the estimates. Once approved, the
> estimate is sent to the client in the form of proposal
> [wireframes, basic use cases and estimates].
> Once the project is approved, the project is run largely on SCRUM
> principles. From all the screens - various modules are identified.
> Based on modules selected by the clients and dependencies [GUI
> design must proceed integration of GUI with backend] sprints
> [generally 2 weeks] are identified.
> For the sprints - tasks are written in detail over the first two
> days. Client is involved in these tasks [written more like
> acceptance tests]. This is the phase where trouble actually creeps
> in. Some of the clients [we work with dedicated clients] can
> indulge in long discussions on what is in scope and what is not.
> For instance, in the example above there could be added
> requirement of double opt-in procedure. Although it hasn't been
> mentioned in proposal, the clients come back with arguments like a
> self respecting website would always have double opt-in for all
> the member registrations.
Well, yes ... but if there isn't a card for it, it's an oversight.
Whose oversight is it supposed to be, the customer's or yours, and
why? Do they "sign off" on the requirements / features / stories in
> I agree that this is not much additional work, but these long
> discussions tend to drag the task formation from two days to
> sometimes three days or even one week depending on complexity of
> module. We tried to start framing tasks one sprint before [I mean
> if team is working on Sprint n, then Managers get working on tasks
> for Sprint n+1], but then it created conflict for manager to focus
> on current sprint in hand. We have tried better communication.
> After everything what it comes down to is even lengthier proposal
> document which outlines more "what is not in scope" than "what is
> in scope".
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 ...
And who's the Product Owner? How do they interact with the process,
with the customer, with the team?
> Another problematic area is the top management starts viewing
> estimates [proposal estimates] as the metric and the teams which
> exceed that metric are categorized as under performers.
> I agree completely that capturing all requirements upfront is
> impossible. Even writing down everything you know in a manner
> which is free from mis-interpretation is difficult if not
> impossible. Hence, my interest in Agile. However, the market we
> operate in is such that if we do not provide fixed price
> estimates, we would be out. And our fixed price estimates are for
> fairly complex projects - where one wrong or erroneous capture can
> be quite costly.
> Perhaps a more possibly question can be - how can we provide a
> fixed price estimate for all the sprints/ iterations up front? Or
> even can we?
You certain can ... you can do the estimates the same way you would
were you not doing Agile. I would imagine that that didn't work very
well in the past, and that it would continue not to work very well
in the future.
Agile does give you an advantage if you choose to use it. Because an
Agile project [done as they are supposed to be] delivers features
from beginning to end, and because it can do any features in any
order, you have the ability to do these things, which can help you
perform to your original estimates:
- do the most important things first, maximizing value to the
- do the most risky things first, giving you more time to respond
to difficulties that will arise;
- do minimal versions of features, to deliver value early, to get
concrete feedback, to ensure basic contract compliance;
- fill in the frills and fancy bits on the features as time
permits toward the later parts of the process;
- be completely up front with the client on what is done, not
done, being done, and allowing them to take part in steering the
project to their best satisfaction.
I don't know how to estimate any better than before I did Agile,
except that I know how to estimate more quickly and simply.
But I do know how to deliver a sequence of features better, which
allows me to do a better job of satisfying the customer within a
fixed and finite budget.
> I am quite a new comer to Agile and Project Management in general,
> but these issues look all pulling in all the directions to me. And
> from what I have read about Agile, if something is not making
> sense, it means that you have not followed some simple and basic
> principles. Unfortunately for us, number of so called gurus either
> have not been of much help.
> P.S. I also agree that having a pre-sales team spending time on
> these proposals is a bad investment especially if we do not get
> the contracts. But that can be for some other time.
Accept your conditions, but not your fate. -- Rod Walsh & Dan Carrison
How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.
- 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?