Search this site
Scrum of Scrums – How the process works, and some modifications / variations
Filed Under Improvement, Issues, Product Management, Product Owner, Scrum | Posted on March 4, 2010
In the previous post (brief overview of Scrum of Scrums), I mentioned the Scrum of Scrums. In this post, will post some more details of how it operates (including some variations), and some scenarios in which it is needed.
When needed
A Scrum of Scrums is very useful when the overall project is much larger than a single Scrum team, and the teams need to ensure that they have a good system of communication going across the teams. The Scrum of Scrums also helps to ensure that the teams are working to remove any cross team impediments This is where representatives from the various Scrum teams get together, work through what activities are happening across teams and also ensure that efficient coordination is happening across the teams. It works to have a ScrumMaster (you can also call him the Uber ScrumMaster) for running and coordinating this Scrum of Scrums. The Scrum of Scrums can meet daily, or alternate days, but lag behind the regular Scrum, since it is the issues that emerge from the regular Scrum that are discussed in the Scrum of Scrums.
Scrum of Scrums – what needs to get addressed
The Scrum of Scrums lasts longer than the regular Scrum meeting, since the issues that get raised at this meeting typically affect far more people than the impediments raised at the regular Scrum meeting, and it makes sense to try and close those issues as early as possible. Team representatives can talk very quickly about what their teams have done, but the major focus is to bring out issues, and to avoid getting into a boasting match about what their teams have done. This meeting is also a good place to walk through higher Product level features that need attention from the Product Management team, or are technically challenging enough that they need to be addressed at a much higher level than the Daily Scrum meeting. The team also reviews the issues raised during previous Scrum of Scrums (maintained in an issues backlog – in such cases, some issues cannot be resolve then and their and needs to be carried forward to another meeting). Using some sort of tool for this purpose is useful, but does not need to be very complicated; in some cases, even Excel or a Twiki is good enough.
Cross Geography Scrum of Scrums
For projects which are located across geographies, such as where teams in different locations are working on separate components that are inter-dependent and which together make up the application, the teams may have their own Scrums at their own location. However, it is pretty important that such teams get together, coordinate, and share notes; and also resolve inter-dependencies. Because of the complication of cross-geographies and different working styles, in such cases, it makes sense to have a daily Scrum of Scrums to make the coordination between them more efficient. In many cases, teams have found that the Scrum of Scrums benefit from having Product Owners and Senior Architects attached to them, attending the meetings when required. One weekly meeting that reviews whether the Scrum of Scrums is having a beneficial effect or needs some modification helps to make the process more tight, more productive.
Ad: 
Scrum of Scrums – a brief definition and some details
Filed Under Agile, Daily Scrum Meeting, Meeting, Process, Scrum, Sprint, Team | Posted on March 2, 2010
What is a Scrum of Scrums ?
Well, if you take any literature that deals with Scrum, you will find the typical team size for a workable Scrum team to be 7-10 people (ignore those articles where it is claimed that Scrum has been made to work with 50 plus team members, since that is more of an ideal case); what happens when you have a larger team ? Well, that is where a concept called ‘Scrum of Scrums’ comes into being.
A Scrum of Scrums is when you have larger teams, and you divide the teams into smaller Scrum sized teams. Each team does their own Scrum meeting, typically at the same time, and then each team send one representative to a meeting where representatives from each team goes. And if you have many such teams, then you can have a Scrum of Scrum of Scrums (and no, I am not making this up).
Who attends the Scrum of Scrums
Since the Scrum team is facilitated by the ScrumMaster, you would expect the ScrumMaster to attend the Scrum of Scrums meeting. Or in his absence, the Product Owner. Well, the advice is different – a member of the team should attend the Scrum on behalf of the team, and this can be any team member. It follows from the above that since any team member can attend, the member who is attending the Scrum of Scrums can keep on changing after every few meetings. However, it is not a total free for all, sending the person who will be best able to project the current position of the team; such as a tester when the team is in the testing phase; or a designer when the project is in the initial design phase. This also means that the Scrum of Scrums can be attended by the ScrumMaster as well.
Can the team send only one representative ?
No, most emphatically no. It actually depends on the size of the constituent team of the Scrum of Scrums. If there are fewer members in the team, then a team can send 2 representatives rather than one. One of these can be a ScrumMaster.
How often does the Scrum of Scrums need to happen?
A Scrum meeting is supposed to happen daily, so does the Scrum of Scrums need to happen on a daily basis as well. No, there is no such requirement. Depending on how the teamwork happens, and how the Scrum of Scrums becomes more efficient, it is very much possible to restrict the Scrum of Scrums to happen only 2 times a week, or maybe 3. These meetings can be different from the Daily Scrums in one significant way; problems can be brought before this meeting and solutions attempted (which is different from the regular Daily Scrum meeting where impediments can be brought up but not resolved to keep the meeting tight).
Further, these meetings do not try to work through a regular backlog of features and tasks, but instead focus more on coordination and inter-team dependencies and relationships.
Ad:
How to optimize Planning Poker as a part of Scrum and some benefits of the Planning Poker process – Part 2
Filed Under Agile, Estimation, Scrum, Team | Posted on March 1, 2010
In the previous post (Optimizing Planning Poker), I explained some points about how to make sure that your Planning Poker exercise was well executed, and estimates generated were good.
In this post, there will be a focus on defining the benefits of Planning Poker, and why you should use that as a way of estimating the effort required for the tasks for every Sprint cycle. Here are some of the benefits:
- Planning Poker results in an open discussion (rather than the normal way of estimation, where a lead or manager asks a few lead developers to do the estimation of features based on many different models of estimation); such a process ensures that team members are able to come out with their own considered estimates, and discuss the reasons as to why they have such estimates
- Planning Poker cards are based on the Fibonnaci sequence, and use the following numbers for estimation (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100)
- The Planning Poker process ensures that the team whole team is involved, and is a part of the overall Scrum process of making the team feel empowered and responsible for the features / tasks; and getting the team feel responsible for ensuring the success of a project based on a Scrum development process is a great way to get started
- With the process such that the team listens to the story / feature, considers and then make their decisions about estimates; but the fact is that the team members don’t open their cards until all of them have made their estimates – which ensures that the team members don’t feel influenced by the estimates of a senior member (which is why it is also critical that the team members make their estimates and only then the estimates are revealed)
- Because you have multiple people looking at the same task, it is possible that one of them may have found an easier or faster way to do the task that others have not found it. In the Planning Poker process, it is easier to ensure that people get a chance to make their views known (however, this can only happen when the Planning Poke process is done properly, instead of just taking an average of the estimates – this is done by teams in a hurry to complete the estimation process)
- Planning Poker is a very simple exercise, especially when you do it with actual cards, and once the team gets over the uniqueness of playing cards, they can actually start enjoying the exercise and the right to be able to provide their own estimates
Ad:
How to optimize Planning Poker as a part of Scrum and some benefits of the Planning Poker process – Part 1
Filed Under Estimation, Features, Scrum, Sprint Backlog | Posted on February 28, 2010
In previous posts (Details about Planning Poker process), I have explained the process of Planning Poker as a part of how to do estimation of tasks during the Sprint Planning process. In this post, I will go further and post some points about how to optimize the Planning Poker process / make it a success, as well as some of the benefits that a team gets from doing their estimation using Planning Poker.
- Even though it is good to get new people on the team for a fresh look, it is essential that there be team members who are experienced in estimation, else the estimates that are generated via Planning Poker could go all over the board, and none of them may be very accurate (this can have its weaknesses in terms of inflated egos, but that can be handled)
- Even though team members are supposed to be self-organizing and empowered and they learn over a period of time, if a person’s estimates remain either grossly over and below the actual efforts even over multiple cycles, then the persons need to be trained in effort estimation
- The tasks / features must be thoroughly explained to the feature team, and they should be able to get any of their queries answered by the product owner
- If a person’s estimates vary greatly from the other team members, then the person should not be scorned, but instead given an opportunity to explain their point of view and the reason for their estimates (without making it a long story)
- The actual process must be followed as follows:
1. Poker cards should be available to all the team members
2. The ScrumMaster details the tasks
3. Team members do their estimation and show their cards
4. If there are wide differences, then people can explain their cards to the rest of the team members
5. Continue this until the estimates converge
6. The ScrumMaster moves onto the next item in the Backlog
7. Continue till enough prioritized tasks are detailed for the current Sprint cycle
Benefits of the Planning Poker in the next cycle ..
Ad:
