We have a long term project, call it Project A. Our direct client (DC) is an organization between us and the Product Owner (PO).

Every now and then we're being asked for estimates. The problem is that the PO comes up with a new feature - well, more like an idea, communicates this to the DC who then tries to get us to come up with an estimate.

Due to the myriad of questions and unknowns we can only give a rough indication. The DC communicates this to the PO as a solid estimate, thus giving us a lot of stress, because when the feature gets built, the estimate is not close to the real development time at all, due to suddenly having to think about edge cases, impact to the rest of the system, etc.

We have tried to educate the DC to gather the requirements up front, but due to his limited technical abilities he's not able to really think it through. On top of that, the PO is all over the place and can change his mind about a feature on a weekly basis.

Is there an optimal workflow to still work with the DC and not leak money going back and forth discussing requirements and get a (mostly) accurate estimate in a short amount of time?

  • No solution to your problem, but you might think about whether your PO fits the definition of a product owner. If your PO is no directly available to you, the development team, it's not your PO. Period. You save time and money by your PO doing their job and cutting out the middle man, whatever their job title might be.
    – nvoigt
    Commented Jan 11, 2019 at 14:57

3 Answers 3


Is there an optimal workflow to still work with the DC and not leak money going back and forth discussing requirements and get a (mostly) accurate estimate in a short amount of time?

Sadly, the answer to this is almost always "no".

In software development there is inherent uncertainty. This arises from several factors, including:

  • Requirements are often wrong because people struggle to define what they want up front.
  • There is almost always some technical uncertainty. The only exception to this is if you are doing exactly the same thing you have done before.
  • People may impact the estimate: new starters, people leaving, sickness, etc.

It can be tempting to think that if you spend more time creating the estimate or if you get better at estimating, that your estimates will become more accurate. Unfortunately the inherent uncertainty may stop this from being true. Usually the effort you spend on estimating has rapidly diminishing returns. That is why a lot of agile organisations use a lightweight estimating process or even no estimates at all.

One possible approach you can take is to allow some contingency. Even this is a challenge as the contingency necessary to cover the uncertainty is often unacceptable to the client.

Another approach might be to ask your client to break their requirements down to make them as small as possible. That way your estimates will be smaller and the size of the error will also hopefully be reduced.

A better long-term solution would be to work more closely with your client using an agile approach. For example, the client could purchase a number of sprints of the team's time. They would work with the team in order to maximise the value that is delivered in this time.


@tiagoperes's Answer is good, but a radical change to suggest. To provide a less radical suggestion: have you looked at the cone of uncertainty?

The idea behind the cone is that all estimates are ranges. The range starts out very wide but then narrows down as more information is gained (eventually becoming a point, once all uncertainty is gone - if you finished the feature in 5.7 days, you know what the 'estimate' is - 5.7 days).

So, when asked for an estimate, give your best-case-to-worst-case range. If/when the person asking complains, explain that you cannot narrow the cone without more information.

At which point they should either collaborate with you to provide more information and narrow the range, or else accept the wide range (and, if using the range for budgeting, accept the worst-case end of it). Or reject the feature, of course.


From what I read in your message, the problem isn't the estimation itself but the whole organization of the team with DC and Devs in charge of PO's responsibilities. So, that middleman shouldn't exist and PO should finish the requirement documents after DC gives requirements to PO. You still work with DC, just in a more organized way.

This answer I'm providing was crafted with the book How to Kill the Scrum Monster: Quick Start to Agile Scrum Methodology and the Scrum Master Role as base, which I think will deal with your problem from the root.

From Waterfall to Agile (Why you work the way you work)

"The issue with this (Waterfall) methodology is that if a project has a big scope, it might take many months if not years until we get final results. A lot of things can change and go the wrong way. Sometimes during the final stage of acceptance and testing, we might discover that the original design stage was wrong. The success rate of a big project executed in this way is alarmingly low"


Overview of Agile Methodologies

"There are three most common methodologies/methods to implement Agile principles: eXtreme programming, Scrum, and Kanban."

Agile Scrum Deep Dive


"The Product Owner (PO) collects requirements from customers (internal or external) and produces the requirements documents. The PO constantly aligns with customers and determines the scope of work and change in the scope, so the PO will get results from the Sprints. The PO is responsible for providing all the necessary product-related information required by the team and providing requirements.

The Scrum Master ( ScMa ) is the servant-leader of the team who helps the team to deliver based on requirements. The ScMa organizes the process and moderates the meetings that will enable the team to deliver. Also, the ScMa provides statuses to the PO or any stakeholders. The ScMa is in charge of resolution of any block and impediments the team faces. The ScMa shelters and protects the team from external teams and stakeholders.

Note: The performance of the individual team members and other HR topics are not the ScMa’s direct responsibility. There is another role Line Manager that is responsible for the performance of individual team members. Line Manager is direct manager for all the members of the Scrum team.

The Architect (Arc) is the technical lead in the team. Often, most of his or her time will be dedicated to guiding other team members, rather than individual tasks. The Architect creates/approves design, reviews code, and works in close sync with the ScMa and PO.

Note: Not every Scrum team has an Architect; however, at least one senior developer on the team should have profound expertise on technical aspects of the work.

The Quality Manager (QM) or Quality Engineer(QE) is the team member responsible for quality management of the product. The QM organizes the quality process in the team, educates the PO and ScMa on quality best practices, and provides quality requirements to the team based on feedback from the PO, industry standards, and best practices (Including performance, security, usability, accessibility etc.).

Developers (DEV) estimate and commit to the estimation on a Sprint basis. They constantly improve the accuracy of the estimation and self-improve from Sprint to Sprint without micromanagement from other roles and managers. Developers distribute between the different expert roles—for example performance, security, and user interface designer.

A Technical Writer (TW) writes supporting documentation for the project. This role can be centralized, since it is usually not required to have a full-time technical writer in the team. However, technical documentation also can be produced by any other role/roles in the team as an additional responsibility."

Your Answer

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

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