Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If you've planned a number of user stories for a sprint and one candidate story is dependent on some external provider delivering something to your team. For example an online service provider adding a new API call to their system or enabling your test account on their system or suchlike.

You know it's coming 'soon'.

Do you go ahead and add the story to the sprint hoping they'll deliver what is required in time for you to complete your story or do you wait till the next sprint, when you know it will be ready and you can start immediately even if it means not starting the story as early as you could.

If the former how do you handle 'unearned' story points lost because of the dependency? partial credit (eek!) or take it on the chin.

share|improve this question
up vote 11 down vote accepted

Ultimately it depends on whether you are 100% confident that the external provider will deliver something you can use by the time you need to use it.

If you cannot be sure that they'll deliver in time they don't add the story to the sprint. However, even if they've always delivered in the past there's no guarantee they'll deliver this time.

You should let the customer know that this dependency exists and that you are going to have to wait for the API (or whatever) to become available before you can schedule the work.

On the plus side, there may be aspects of the story you can deliver - i.e. break it down further until you've isolated the dependencies as much as possible. This might allow you do some of the story before the supplier delivers their work.

share|improve this answer
Would you ever suggest 'faking' the API if it's not too much trouble? – JeffO Oct 3 '11 at 13:28
@JeffO - well that depends. If you need the real results then it could be a problem and API's have been known to change. – ChrisF Oct 3 '11 at 13:30
@JeffO I wouldn't fake an API in isolation, but you could see about agreeing on a common interface that you can code against. Even when the third-party components come in, protecting your code against directly calling them is not a bad idea. – Adam Lear Oct 3 '11 at 13:39
So in Project Management, this is Risk discussion. – Jamie Clayton Feb 21 '14 at 11:48

The team is the one that makes the commitment. In our team, if we feel we're waiting for (for example) an external developer, we have learned to say that we're not willing to pick up the story. The story is not in a fit state to pick up.

Theres a very good chance that the late, unexpected, or different delivery from the external resource will mean your estimates and priorities might change.

Until you have all the info, the team shouldn't be so naive to think they can complete the story. If they say they can, then it arrives late, in an expected format, or not at all, they've let everyone down.

Sounds harsh but I want to get my point across.

share|improve this answer

In Scrum there is a definition of done and there is a definition of ready for user stories. In a situation like yours its important to has a definition of ready that all the stakeholders understand and agree with. For example seems very reasonable to has a line in your definition of ready like:

  • All the external API's needed for the story must be delivered and tested.

If you needs this API to add value to your product the logical thing to do its wait until we really have this API to start our work. In the meantime we can do other US that add value to the product, i really don't like this US with mock implementations and the like, if there is not real value for the costumer there is no US, its waste of time and resources.

share|improve this answer

If you are waiting for something you don't know yet than you cannot plan it even if you are 100% sure that it will be delivered tomorrow. Why? Because if you don't know it you cannot even estimate its complexity and if you cannot estimate it you cannot plan it.

If you defined some "interface" / "contract" upfront which must be followed by external company you can plan it and create service mock on your side. Your development will use the mocked service so they will not be dependent on external delivery. Still development with mock should be planned for sprint where real service will be delivered because feature developed and tested against mock is not completed - it must be tested with the real service to be considered as completed at the end of the sprint.

share|improve this answer

Communication and Agreements

Two systems are integrated by programmers, not by the methodology itself. If a company has decided to integrate an external system, there will be a contract between (minimum) 2 entities. The contract must ensure that integration takes place. Consequently, if the agreement between the companies, does not require a technical collaboration between both departments, the problem is not the development methodology. The problem is business methodology (basically the contract).

Having said that, it must be considered a risk during the planning of those cases and considering that you do not know the speed of the team, you will need to be generous with those margins.

How can a Project Manager manage a dependency on an external team?

share|improve this answer

If it doesn't depend on your team and you can do other tasks, I advise you to only take it when it's ready. Even if you got an mockup webservice, schema, interface and/or contract it may still break up (remember Murphy's Law?).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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