2

So me and my team have been doing estimates for a new project but we have been getting the feeling lately that the customer has trouble understanding not the estimates in itself but what the stories described actually contain.

We have been thinking of going through their RFP documentation and in this document make a connection to our excel list with estimations saying "this part is contained within this estimate". But this approach seems to me to be very time consuming and there has to be a better way to make sure that we cover what they expect us to cover in estimates while not making it too hard for them to understand.

My question: How would you approach a customer with estimates? In what format would this be? and foremost, how would you make sure the customer understands what you have estimated and what this story contains and thus rule out - for the most part - confusion between the two parties being my company and the customer's?

Edit: I do not think this is covered by the question proposed as duplicate since this question is more on presenting the estimates and omitting confusion between what is and what is not covered by it and the communication of this to the customer; while the duplicate presented is more of a way to have a client choose for agile and what to do if he does not, and the practices hereof.

Edit 2 on Comment of Thomas Owens: The customer provides the requirements through a full text document describing their processes as best as they can and what it is that they want. Note that this might be large or complex things which we have then subdivided ourselves and written down in order to make a better estimate. The product owner is one of the customer's employees who is closest involved to the new application they want us to create but is not fully sure on all the details; leading to a lot of uncertainty on - for example - financial formulas and how they should be used.

What we have done is create a list in Excel with the processes (possible stories but not as such) described and trimmed down or split up to try having a better understanding on what each part contains; not so much technical but functional.

i.e.

enter image description here

Note this image is a trimmed down version for confidentiality reasons

Improve this question
2

2 Answers 2

Reset to default
9

I think you've confused the customer with your internal teams.

The customer has given you a RFP and you've turned it into a set of user stories, assigned estimates to these and then gone back to the customer with your (internal) analysis. The customer has (quite rightly) looked at these and said "what's this got to do with what we originally asked for?"

As far as the customer is concerned, what you do and how you do it is entirely up to you. What they want to know is how much of their request they will get and how long it will costs them (or how long it'll take), so you have to communicate with the customer in their terms.

So when you turned their RFP into stories, you should already have been tracking which story corresponded to which part of the RFP. Then it should be an easy matter to roll the story estimates up and put them back into the RFP. If you didn't do this, then you'll have to take the hit now (which has a benefit of checking you have covered every part of their RFP,how else do you know if you've not missed something)

eg,. if the customer asked you to "make a widget", and you turned that into 3 user stories of "cast widget", "polish widget", and "box widget", you can add those 3 story estimates together to give the customer the answer they're looking for.

Improve this answer
1
  • We have - as you suggested - reverted to the document and are going through this linking whatever items we have to the story or stories we described so the customer has a kind of "link" to the estimates. Thank you for the help.
    – Tikkes
    Dec 2, 2015 at 14:31
2

Forgive me, but I think you've rather put the cart before the horse. Whenever I've dealt with a RFP/ITT etc, the client is really looking for a high-level idea of your approach to the problem. This happens for a number of reasons:

  1. So they can be comfortable that you understand the requirements such as they are
  2. You can demonstrate the technical nous required to deliver
  3. You've managed to read between the lines and cater for any pitfalls endemic in the functional area at hand
  4. Can pitch all of the above at a sufficient level

The breaking down of the requirements into tasks comes after this process has been completed.

Improve this answer
1
  • I completely agree that this should indeed be a later process but the client we are dealing with already wants a very detailed list which is making our tasks a whole lot more difficult.
    – Tikkes
    Dec 2, 2015 at 14:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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