If during a sprint some task depends on customer development, should the customer developers considered as part of the team?
At the sprint planning meeting should these developer attend to share how much time to be done for that task?


I think that you should do everything you can to make these people part of your team. That will mean that they will follow the rules you set up in the project. That will mean that you will control the situation much better, and will achieve project objectives with much higher confidence. Thus, the answer is "YES, OF COURSE".


I feel customer's developer (may be the team lead) can take part in the sprint planning. This is to keep everybody in "same page" and make sure everybody know what schedule they are on and to know the plan for "getting the thing done".At the same time, they need not be active in other meetings.


No - you don't control their schedules or manage them.

This can only lead to finger-pointing.


No, you manage them with Procurement Knowledge Area, If they are apart of the project team, they should be managed as a procurement.

  • Well, I didn´t see the Agile and scrum sorry ma bad. Then yes is a good idea to include a Customer Lead Developer. If we were managing using PMP Framework this should be considered different, as a procurement. Feb 17 '11 at 17:18

Not a bad idea, in my opinion. It certainly will improve buy-in and understanding. However, if it's only for a single sprint, I'm not sure if it is worth it.

But even if you do, I'd still manage this as a dependency to your project and follow it up very closely.


The ideal way to coordinate would be to have that person sit in on your scrums, or to have a representative do so to report status. This will keep communication open, which is the only way to reliably coordinate dependencies outside of your team.

If this is not possible, I would create a story to have a team-member manage the relationship -- touch base with the customer, give and get status and progress, and make sure things integrate well once they deliver whatever they deliver.

Because at the end of the day, you will have to integrate their work with yours somehow. Even if you treat it as a procurement. Best to identify it as a story and manage it proactively.


Unless they become a full member of the team I would say no. They would not have any commitment to your sprint goals.

Instead I would organise an extra daily (short and time-boxed) meeting with external dependencies. This could be with developers from other teams, other companies or external designers. Some could call it a sort Scrum-of-Scrums meeting for externals.

I have worked in a team where we where depended on another (external) teams Web-service / API. The daily meetings where a great place to discuss impediments we would run into and to discuss upcoming changes to adapt (update the backlog) in time. If you are fully depended on a feature of the other team (that they need to deliver in the same time span), I would suggest to mock their work so you can deliver a "working" product within the sprint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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