How do I manage burndown in a Scrum Board when an issue in a project is assigned to someone I have no control over?

[Dave Boal]

I am responsible for members of my own team. I am not responsible, nor do I have any control over the members of other teams who assist us in resolving our issues.

For example, once we have finished coding, the customer's test team performs acceptance testing. Even though we are temporarily done coding the issue, we don't mark it as resolved until the code is deployed. What we do instead is assign it to a member on the customer's test team, and when they are done, they assign it back. However, since they were not part of the original estimate, whatever work they do, delays our project burn down.

To resolve this issue, I suspect I need to add subtasks for every type of task that will be performed, including all tasks performed by all teams. When a subtask is ready to be performed, it can be assigned to the appropriate person. That person's team would be responsible for everything about that subtask from the moment it is created, including estimation, assignment and resolution.

Each Issue's Subtasks I suspect would include Investigate, Estimate, Write Test Driven Development Tests, Code, Development Testing, Team Review, Customer Acceptance Testing, Documentation, Deployment Planning, Deployment.

As far as statuses, I suspect Open, In Progress, Resolved, and Closed will be sufficient.

So that brings me to my question. Is this the best way to handle autonomous teams on one project and one issue?

I appreciate your experience in this matter. Thank you!

[Dave Boal]

It definitely was a management issue. We changed our deliverables from "deliver a working project" to "deliver testable code" and "deploy code", eliminating us from responsibility for external Testing projects. Our burndown charts now look much better.  Ivar Sønstabø Thank you for sharing your perspective! 

[Ivar]

I would raise this as a management issue @Dave Boal. The burndown graph indicates the progress of the team. In your case, you might be in a world of hurt because the customer's acceptance team might not be testing an issue before a week has gone. And with the process above, you will not be able to burn those points before they have tested it, and, if no bugs are found, closed it. Worst case, an issue might go back and forth for quite some time before it is closed, and the points are burned. 

Why is this a management issue? Well - what kind of contract do you have? Does it place any restrictions on the customer in this case? E.g. acceptance test should be done within X time or similar? Can you get the customer to commit more? You say nothing about the type of project - is it agile or sequential? If agile - is it possible to get the test team more included in the team? 

This issue is a year old - did you solve the problem?