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?
Tell me more
×
Project Management Stack Exchange is a question and answer site for
project managers. It's 100% free, no registration required.
|
|
||||
|
|
|
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 manage them with Procurement Knowledge Area, If they are apart of the project team, they should be managed as a procurement. |
|||
|
|
No - you don't control their schedules or manage them. This can only lead to finger-pointing. |
|||
|
|
|
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. |
|||
|
|
