SCRUM of SCRUMs meeting questions

While reading Succeeding with Agile, I rather enjoyed Chapter 17 which was on scaling SCRUM. Here's a brief explanation of what was covered.

When coordinating work among several SCRUM teams, it is beneficial to hold SCRUM of SCRUMs meetings. These meetings differ from standard daily SCRUMs in that they are not timeblocked to 15 minutes. They allow groups of teams to discuss issues that pertain and focus on areas of overlap and integration. Such issues can, if not regularly settled, compound and critically hamper production.

When selecting who should attend from each team, it's best to choose a technical contributor (programmer, tester, designer) rather than the Product Owner or ScrumMaster. Your attendee can vary from meeting to meeting. Select the attending member based on who is best suited and knowledgeable about the state of the current sprint. The goal of the meeting is, as was previously mentioned, to remove barriers and efficiently sooth issues that arise from cross-team-dependencies.

Mike Cohn describes the differences of SCRUM of SCRUMs and daily SCRUMs as:

- They do not need to be held daily
- The do not need to be timeboxed to 15 minutes
- The are problem-solving meetings

Hosting a SCRUM of SCRUMs meeting

First off, you should only host 2 to 3 meetings a week. If you find that you need more, then you should analyze your sprint planning process.

Meetings should allow for each attending member to have 15 minutes to go over the following three questions:

1) What has my team done since we last met that could affect other teams?
2) What will my team do before we meet again that could affect other teams?
3) What problems is my team having with which it could use help from other teams?

After each member has had the floor, the focus should switch to any pending issues on the issues backlog.

Story Points

What are Story Points?

Story Points are units of relative size used in estimating software requirements. This is an alternative measurement to time based analysis. Points are estimated by assessing complexity rather than duration. Story points work in conjunction with User Stories.

What are they good for?

Story points are a fantastic way to estimate how long it will take to finish a product. They replace the standard time-based estimate with a more detached concept. Story Point is not the only vernacular around to describe this measurement. Some XP teams also call them cheezits or acorns.

We use story points when estimating for the long term, for instance against the entire product backlog. It's not a good idea to use them in planning for a particular sprint, as sprint velocity will vary.

Good quote from Mike Cohn on Velocity,

"This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.

Velocity will bounce around from sprint to sprint. That’s why I want teams to plan their sprints by looking at the product backlog, selecting the one most important thing they could do, breaking that product backlog item / user story into tasks and estimating the tasks, asking themselves if they can commit to delivering the product backlog item, and then repeating until they are full. No discussion of story points. No discussion of velocity. It’s just about commitment and we decide how much we can commit to by breaking product backlog items into tasks and estimating each. This is called commitment-driven sprint planning."