How to handle unconventional backlog items involving integration with a third party

Vasan,

What is your role on the Scrum team? Have you asked the Team for their advice? There is a lot of "I" and "me" in your question, which implies that you also play some authoritative role as a manager or team lead. Is that true? Do you play any other organizational role than what you play on the Scrum team?

Regarding the work... Is the other team using Scrum or Waterfall? Is the 3rd party team internal or external to your org?

I think anyone would need much more context around your question to give any decent advice.

And one more interesting question -- is there a clearly defined technical interface(ReST, SOA, etc) between your system and the 3rd party system? If not, then how do the two systems communicate?

Fully agreeing to what Charles has said, it is a fact that end of the day it is your team - as a whole need to be comfortable with what is being planned.
Coming to your specific situation:
If your 3rd party is not syncing with you, you are basically creating a dependency on them to close their piece of work & then you may go ahead & integrate (or perhaps while integrating, you need the hand-holding from this 3rd party). So, eventually if your team is dependent on this, you need to get a commitment from the vendor towards - (a) completing their work by a specific time and/or (b) ensuring they provide support when you integrate.

Based on this, we can think of 2 possible approach:
1. You may create your integration activities once your vendor complies to the points mentioned above (you should be having some kind of SLA)
2. Even better - why wait for this to happen separately, get in to an agreement with your vendor - go for a Continuous Integration.

I honestly don't have much info on what is the technicalities involved in your project, But given an option, we should go for CI always. Doesn't that work for your context?

Hi Vasan

You say that the third party doesn't follow Scrum. I don't mean to sound critical, but it seems that your team isn't really doing Scrum either, because you do not wholly own your process. You are dependent upon that third party if your work to meet your own Definition of Done.

Now, the best thing to do is what Arijit has suggested and seek better integration with that third party. Scrum doesn't prescribe a way to do that, but there are enterprise-level frameworks that do, such as SAFe and Disciplined Agile Delivery. If you haven't already done so, I suggest that you look at these methods and do some googling around what they have to say about Release Planning.

What you are feeling the pain of agility at scale. These sync points are troublesome to us all, regardless of whether they occur inside or outside of the organisation. As you point out these dependencies may not be working in an agile way themselves. This makes your own ability to make a timely commitment, or even a sensible forecast, difficult indeed.

Here's something you can do. It isn't a solution, but it is a palliative that may be useful until better integration is in place. You can write smaller stories that wrap the dependencies themselves. So if you can only part-complete a story before the third party gets involved, write a story that takes the work up to that point. Phrase it in terms of the value that is being delivered to the third party, and which allows them to do their part. Once they have done their bit, you can progress other stories that represent the remainder of the work. These other stories can stay in your Product Backlog - since you don't know when the third party will be done, you can't plan them in to a Sprint yet. The underlying principle is this: if you can't remove impediments, plan around them. Don't plan for impediments to happen, and for your work to become blocked.

Incidentally, matters of product integration should involve the Product Owner. The Scrum Master and the Team can only be expected to meet Sprint commitments for work that falls within their control. Where is the Product Owner in your case? As Charles has pointed out, you've made heavy use of the "I" word when multiple stakeholders might reasonably be expected to be involved.

Well, the best that can be said is that you must follow the sprint time and tasks to complete in that time frame. This will give a certain reliability factor and lets you plan ahead for both you and the third party.

http://www.agiledistributed.com/

Thanks all for your views and comments (apologies for not updating this post earlier -- notification mails from scrum.org were landing in my Spam folder for some reason and I didn't notice it).

Charles, you are right, I am the manager. The interface with the other system is Web Services (SOAP). The other team is external to our organization, they don't follow waterfall or scrum. They don't even have a proper source code control system!

The team is frustrated with the vendor and wanted me to change the vendor, which I am afraid is not possible. Today, a developer (she'd done some reading up on this) suggested we shouldn't take up the backlog item till we we have tested the vendor's deliverables. I thought this was a reasonable option. It's what Arijit said as well -- what is not under the team's control should be a pre-requisite to the backlog items. Thus, what the team commits to will be fully under the teams control. Arijit's other option (bring the vendor under our fold) is worth trying out as well, but that requires me to coach the vendor's team also and bring them in sync. Maybe next release.

Ian: thanks for your pointers on SAFe etc. I will look these up. The product owner is the one who chose the vendor, and is well aware of the situation and sympathetic. He accepts delays and unpredictability of this deliverable, It's me who's bothered (perhaps overly).

> Today, a developer (she'd done some reading up on this) suggested we shouldn't take up the backlog item till we we have tested the vendor's deliverables. I thought this was a reasonable option.

Given your experience with that vendor, that is a very reasonable option. While "waiting for external dependency" resolution is one good strategy for external dependencies, you can also do them "in-line" so long as you are 95% sure that your external dependency can meet your in-sprint timeframe and deliver on the sprint boundary. In your situation, it sounds like the former is a better option than the latter.

The interesting part about web services is this. Your web service should have very clearly defined entrance and exit criteria on the service. The entry and exit from that WS *IS* your story/PBI. The fact that your service doesn't integrate with some other system's service is not really a PBI. If you find, through integration testing, that something doesn't work right -- then you have to figure out whether the bug is in your service or theirs. If the bug is in their service, then there is no PBI for your -- it's simply a task to re-test at some point. If the bug is in your service, then there is a new PBI or task that needs to be resolved. Remember the boundary around *your* system is the web services input and output. The rest is just some integration stuff that has to happen.

It also sounds like your vendor is not delivering what they promise (due to their functionality not working properly). That's an impediment that needs removing.