How to deal with non agile teams

Question

We are currently facing this problem in a scrum team.

Imagine you a have a user story with a front-end part which calls a webservice to get some data. Imagine that your scrum team do back-end,front-end and testing but the webservice part is done by another team in another country and you can't expect this WS to be delivered in the current sprint so the US can't be finished.

The question is how do you reflect this in the process, some ideas:

1. Split the US with Front Part + WS part. And try to put forward the WS in an early sprint. (Acceptance Criteria of the whole US should be defined at the time de WS story begins). Do you set Story points to this WS techical story?
2. Do not Split, start in the sprint N and end the user story in N+1 or N+2... How do you plan capacity of sprint with this kind of stories.
3. Any other approach?

Important note, we can not abuse of using the other team, so we can not split the ws by a light version and then a more elaborated version.

Thanks.

Answer 1

One thing to consider would be to have your team mock up the WS endpoint that the other team will be creating. It may be out of their scope of influence, however if they are able to get that up and running it should provide additional testing value in the future. Creating the mock service -- a real stand-alone, or being able to mock using say a feature toggle -- will allow for their system to be stable and testable even when the other system is down.

As for selling this to the company/PO, you can use the additional cost incurred by creating the mock service to drive home the point that planning across teams is important, and that the other team is inducing the cost. Alternatively, you could sell the merits that I mention above (especially if you get buy-in from your team), and possibly use the technique elsewhere to reduce cross-team dependencies.

Answer 2

A common approach is to have a user story represent the delivery of business value. In the situation where you do the front/back-end development but don't yet have the web service complete you cannot claim to have delivered business value.

There is also the question of your definition of done. Say you complete your work and a sprint later the web service is delivered. You test your code with the web service and find bugs. You can only really say the work is 'done' once the bugs have been fixed. That would suggest you were not 'done' when your part was completed, only when the integration with the web service was complete.

Another reason for this approach is that you want to reflect the teams true output of business value. Say your team was moving more quickly than the team producing the web services. You would race ahead and appear to be generating lots of value. But the reality is that business value is only available once the web service work is done.

This produces an interesting dilema. Is the capacity of the team how much work they can do, or is it how much work they can get to a state of 'done'?

I would argue that you would be better off using approach #2 and only award the team story points for stories that have been integrated with the web service. That way you reflect the true velocity of the team.

Answer 3

I'd think user story would need to have as little dependencies as possible, so i would go for option 1.

If you're able to mock/stub the dependent parts you are able to finish quite much in the first part already.