13

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.

Improve this question

6 Answers 6

Reset to default
12

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 then don't add the story to the sprint. However, just because 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.

One thing you could do is to create an interface between your code and the third party API. You code to your interface so the rest of the project can proceed and until you have the real API use a mock to return example data. Then when the real API arrives you just have to change the code behind the interface which won't affect the rest of the application. Only do this if you can agree with the the API's supplier that their interface won't change (at least not drastically).

Improve this answer
4
  • Would you ever suggest 'faking' the API if it's not too much trouble?
    – JeffO
    Oct 3, 2011 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, 2011 at 13:30
  • 2
    @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, 2011 at 13:39
  • So in Project Management, this is Risk discussion.
    – Jamie Clayton
    Feb 21, 2014 at 11:48
12

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.

Improve this answer
4
+25

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.

Improve this answer
1
  • There is no Definition of Ready in the Scrum framework. It is an addition, sometimes a traditional phase gate, that some organizations use.
    – Alan Larimer
    Mar 19, 2018 at 22:02
2

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.

Improve this answer
2

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?

https://pm.stackexchange.com/questions/1400/how-can-a-project-manager-manage-a-dependency-on-an-external-team

Improve this answer
1

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?).

Improve this answer

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