5

To set some things straight. I have got experience with scrum and I know how the planning process goes in a Scrum project.

The question I have relates to the start of a project. Let's say I as a PM or Scrum master get a document from a client where it says roughtly what he wants.

  • An online platform
  • Some information what the website is about (lacking many details)
  • Various couplings (of which the description is ambigous)
  • And some deadlines.

Now the client wants a price quote. Now the question is how to go about this.

  • The customer wants his product on Time
  • We both don't want to have disagreements about the delivered work.
  • Was it promised or not. The customer wants a price quote while the specs are not clear yet

I would like to know how others deal with this problem.

| improve this question | |
11

In agile a price quote is given in terms of the cost of hiring a team for an iteration. The number of iterations is variable and depends on changing requirements.

If your customer insists on a specific quote then they are probably not interested in doing agile. Another possibility is that one wants to propose agile development to a customer that does not know it.

If the proposal is appropriate, then agile must be explained first. Once the customer accepts to work in an agile manner, then it becomes obvious that a quote is in terms of a "per month" quota and not as a package.

Typically a team will deliver minimally working software within 1 or 2 iterations. So your customer will get "version 0.1" in 2-4 weeks. It's up to them to decide if to proceed and spend more or if not.

Of course, you can give a general estimate by comparing with other projects, but at the end of the day -- agile work is not a fixed-scope, fixed-cost matter. It's open-scope, and fixed regular deliveries which are planned on the go.

I am not so sure what else your customer would expect.

| improve this answer | |
  • A customer would want to know how long it would take to get a finished product. If I will tell him, well just buy a sprint or two, he will have no guarantee that he gets what he wants after the sprints are finished. – sanders May 11 '14 at 21:18
  • 3
    @sanders Of course there is. They will get a potentially shippable product consisting of two weeks of work. The whole point of agile is that "finished product" is not predefined. A customer can walk off after every iteration if they don't want to continue - and a team's job is enabling him to do so if he so chooses. – Sklivvz May 11 '14 at 21:30
  • @skilvvz, that may work for some clients, but it certainly doesn't work for all of them. You are based in California/New York - the rest of the world is playing very slow catch-up to the notion of 'innovation everywhere'. By the time you move out from coastal america, things get very different indeed. Annual budgets are often controlled against product (not service!) deadlines and software is still often considered to be a product, not a service. In many contexts 'Explaining Agile' to a large multinational won't do anything but lose you the opportunity. – Konchog Jan 10 '18 at 7:50
  • 1
    @Konchog I am based in Italy... and I've been doing this kind of estimation for 12 years. You are right, sometimes clients are not comfortable with agile. Don't use agile if you don't have buy in. Don't tell your team they'll be doing agile with a non-agile customer. Etc. Just be honest and transparent. – Sklivvz Jan 10 '18 at 9:15
7

You can almost spend infinite amounts of money on software, therefore an important question to ask is, how much are you (the customer) will wanting to spend.

If it is feasible to create something for their project, in that time, then you can introduce them to the process of Scrum.

Scrum aims to keep quality and time fixed, you can however adjust scope. If they aren't interested in being involved in the Scrum process (as frequently happens), then it is not the methodology for you.

Agree a minimum scope and the rest is prioritised backlog.

There are other answers to your question, but this should be the default position for a Scrum team.

| improve this answer | |
1

I am currently working on a paper and it is also to some degree related to this issue.

In the literature there have mentioned several solutions. Indeed, the selling of a number of iterations is an option. However, you could allow the customer to swap requirements in later stages. There are several clauses that can be added to the contract, which will reduce your risk but also give the customer a fair estimation of the cost. However, it is often hightly context dependend.

Perhaps a target-cost (sharing the pain/gain) might be feasible solution? But it will also depend on your relationship with the customer. However, if the customer does not accept scrum to manage the development, other solutions might be needed. Again, it will depend on the willingness of the customer also.

| improve this answer | |
1

What we do is to have a go at the number of iterations, based on existing experience, and look at the size of work involved in each iteration, based on existing experience. Look how the job differs in scale or size from other existing jobs. Make a good guess on the number and scale of iterations, and then multiply that by 150-200% - for an itemised quote, this may mean adding 'phantom' iterations.

An important thing to remember is that no-one is unhappy when you come under a quote, but everyone is unhappy when you come over.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.