{"id":4571,"date":"2023-12-11T11:45:26","date_gmt":"2023-12-11T10:45:26","guid":{"rendered":"https:\/\/p4dev.hardscrum.com\/?p=4571"},"modified":"2026-02-17T12:44:10","modified_gmt":"2026-02-17T11:44:10","slug":"team-collaboration-poker","status":"publish","type":"post","link":"https:\/\/p4dev.hardscrum.com\/en\/team-collaboration-poker\/","title":{"rendered":"Team Collaboration Poker"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n

Team Collaboration Poker is used for group-based discussion and negotiation of collaboration between two teams.<\/p>\n

Collaboration between two teams can be very different and diverse. The card game is based on a typical situation of an application team and a service or component team, whereby the service or the component to be developed (or extended) is to be integrated into the application. When defining the collaboration, the focus is on which team takes on which tasks and responsibilities. The following options are available:<\/p>\n

    \n
  1. Order:<\/strong> Team A only orders the service\/component change and the application integration at Team C. All work is reflected in Team C\u2019s backlog. Team C does all work.<\/li>\n
  2. Partialy Integrate:<\/strong> Team A orders the service\/component change done by Team C. Application integration is partially done by Team C and A. Work is reflected in both backlogs.<\/li>\n
  3. Integration by <\/b>temporary<\/b><\/u> C Supporter: <\/b>Team A orders the service\/component change done by Team C. Team C member temporary moves to Team A to do the integration. The capacity of both teams temporarily change!<\/li>\n
  4. Integration by <\/b>permanent<\/b><\/u> Extended C Team: <\/b>Team A orders the service\/component change done by Team C. An Extended Team member of A&C integrates the component in Team C\u2019s context. All work is reflected in Team C\u2019s backlog.<\/li>\n
  5. Integration by <\/b>permanent<\/b><\/u> Extended A Team: <\/b>Team A orders the service\/component change done by Team C. An Extended Team member of A&C integrates the component in Team A\u2019s context. Integration work is reflected in Team A\u2019s backlogs.<\/li>\n
  6. Integration by <\/b>planned <\/b><\/u>C support activity: <\/b>Team A orders the service\/component change done by Team C. Team C supports Team A to do the integration together with Team A. Integration support is reflected in Team C\u2019s backlog.<\/li>\n
  7. Delivery only: <\/b>Team A orders the service\/component change done by Team C. Team A does all the integration work alone. Integration work is only in Team A\u2019s backlogs.<\/li>\n
  8. Partially Independent: <\/b>Team A does the service\/component change alone. Team C only supports Team A to do the work. The work is reflected in Team A\u2019s backlog, except the support in Team C\u2019s backlog.<\/li>\n
  9. Fully Independent: <\/b>Team A does the service\/component change and the integration alone. Team C is not involved. All work is reflected in Team A\u2019s backlog.<\/li>\n<\/ol>\n<\/div>\n
    \n

    But why “group-based”?<\/strong><\/p>\n