Life Science Journal 2014;11(8) http://www.lifesciencesite.

com

Scrum of Scrums Solution for Large Size Teams Using Scrum Methodology

Saja Al Qurashi, M. Rizwan Jameel Qureshi

Faculty of Computing and Information Technology, King Abdulaziz University, Jeddah, Saudi Arabia
saja_alqurashi@yahoo.com, anriz@hotmail.com

Abstract: Scrum is a structured framework to support complex product development. However, Scrum
methodology faces a challenge of managing large teams. To address this challenge, in this paper we propose a
solution called Scrum of Scrums. In Scrum of Scrums, we divide the Scrum team into teams of the right size, and
then organize them hierarchically into a Scrum of Scrums. The main goals of the proposed solution are to optimize
communication between teams in Scrum of Scrums; to make the system work after integration of all parts; to reduce
the dependencies between the parts of system; and to prevent the duplication of parts in the system.
[Qurashi SA, Qureshi MRJ. Scrum of Scrums Solution for Large Size Teams Using Scrum Methodology. Life
Sci J 2014;11(8):443-449]. (ISSN:1097-8135). http://www.lifesciencesite.com. 58

Keywords: Agile; Scrum; Scrum of Scrums; large team; Scrum meeting; daily meeting

1. Introduction The Scrum of Scrums meeting is different from

The software development domain must keep the regular Scrum; we describe these differences in
pace with ongoing changes in the environment. Agile later sections. The rest of the paper is organized as
methodology is a perfect choice for any organization under. The related work is reviewed in Section 2.
to produce their product in short time. Scrum is an Section 3 describes the exact problem statement. Our
agile methodology, which is a framework structured proposed solution is described in Section 4 and 5.
to support complex product development. There are Section 6 describes the goals we established and a
three core roles in Scrum: product owner (PO), survey based on our goals to validate our proposed
Scrum master (SM) and Scrum team (ST). The PO is approach. The study is concluded in section 7.
a key stakeholder of the project and is responsible to
visualize and prioritize the features list for the 2. Related Work
product. The SM ensures that the Scrum process is Azham (2011) proposes the integration of
going as agreed, and prevents any impediments that security principles in development phases using
can be faced by the team, e.g. communication, Scrum and suggest the element of security backlog
dependencies, etc. All the members working together that can be used as security features analysis and
to complete the set of work they have collectively implementation in Scrum phases. But the result of the
committed to complete within a sprint comprise ST. proposed solution will be presented in the near future
The main feature of Scrum is reduced time and small after enough data has been collected from various
team size. Organizations employ Scrum methodology surveys, interviews and experiments that are
to complete large projects in short time. In case small underway and planned (Azham, 2011).
team size is inappropriate to finish a project in time, Chhavi et al. (2013) present Scrum to complete
large teams are set up. The large teams in Scrum the work in short iterations. Automation can be
methodology may have several problems including beneficial at time of managing various activities of
duplication of work, communication failure, Scrum. It provides fast solution, increase reliability,
integration with other teams and dependencies repeatability, comprehensiveness and efficiently.
between tasks in different teams (Mundra et al., There is a need for more research about automation
2013). of Scrum (Chhavi et al., 2013).
The Scrum of Scrums provides solution to these Noor et al. (2013) observed the progress of a
problems. The Scrum of Scrums meeting is an project that used Scrum, through burn down charts,
important technique in scaling Scrum to project where remaining task are plotted against working
where large teams are required. These meetings allow days and actual progress line are compared to overall
groups of teams to discuss their work, focusing on progress. They proposed the modified version of
areas of overlap and integration. The attendees of the original burn down chart. But we must try to upgrade
meetings should change over the course of a project. the chart in the future to identify more reasons of
The team should choose its representative based on deviations (Noor et al., 2013).
who will be in the best position to understand and Raghaw et al. (2012) present a study to identify
discuss the issues that arise at that time during a important issues and challenges that effect quality of
project. game development by agile method. These

443
 Life Science Journal 2014;11(8) http://www.lifesciencesite.com

challenges include team management, lack of nonfunctional requirements. The project management
accountability, trust and confidence, documentation, requires suitable quality metrics that would be used
work environment and training. They proposed the to design a risk driven algorithm to prioritize, plan
following guidelines: each member in the team must and improve implementation sequence. Non-
have knowledge and skills pertinent to the project the functional Requirements Planning (NORPLAN)
team members are going to work on; the project proposes two additional prioritization schemes
manger should not be a bottle neck to Scrum teams; (Riskiest-Requirement First and Riskiest-
new employees should be given enough time to Requirement Last). However, there is a need to
understand the system and Scrum method; the project incorporate other required quality metrics and
manager must watch if there is a lack of trust and validate NORPLAN in real world agile software
confidence; the duration of Scrum meetings should requirements planning teams (Farid et al., 2013).
be strictly observed; reduce documentation Guang-yong (2011) presents the software
significantly. But the main limitation is that the engineering research and practices to improve
project narrowed down for two firms only (Raghaw software quality and productivity. During the
et al., 2012). process, the project team developing vehicle spare
Akhtar et al. (2010) reported that Pakistan's parts management system, import Scrum agile
software industry is comparatively young as software development using visual studio 2010 as the
compared to the global software industry. So it is Scrum process management template. Scrum
flexible to adopt new project management practices implementation increases team productivity and
and software development methodologies. The quality. But we must explore the continuous
Scrum adoption, implementation and acceptance in expansion and improvement in Scrum, particularly in
Pakistan's software industry will be helpful for the area of performance evaluation for in-depth
making accurate decision. But, so far the Scrum is research. In addition, we must examine how to
not very popular in Pakistan's software industry further the integration between different roles
(Akhtar et al., 2010). (Guang-yong, 2011).
Vlaanderen et al. (2009) present a case study of Akif (2012) determines the challenges and
software product management based on Scrum issues in Scrum implementation. Issues identified
method. They argued that the product manager can from the survey includes: quality items pileup,
cope with complex requirements in agile module integration issues, code quality, disruption in
development environment. But, their work requires team work, backlog management, multiple teams,
further elaboration and formalization of requirements metrics, no technical practices, risk management,
of agile SPM process (Vlaanderen et al., 2009). mature vs. immature Scrum, sprint duration, release
Harsimarjeet et al. (2011) present PEOR model, process, lack of Scrum training, documentation, too
which focused on how team members should idealistic Scrum and communication/Scrum
function to improve organization performance in ceremonies (Akif , 2012).
continuously changing situations. This model
minimizes the problem of overtime by continuously 3. Problem Statement
monitoring the performance of team members and The agile methodology is an optimum idea to
thus increasing customer's satisfaction. The limitation implement a product. The Scrum methodology is one
of this model is that it is proposed for an environment of the popular methodologies used in organizations.
where workers are not permanent (Harsimarjeet et al., But the main problem in the Scrum is the team size.
2011). The Scrum team is usually between 7-9 members and
Nishijima (2013), presents the applicability of most organizations want to create big projects and
agile methodology specially Scrum in traditional need a larger team. However, in a single project large
development environment. The main problem is size team may have many issues. This paper attempts
cultural resistance to change within organization. to address the problem of fixing the issues in setting
This work encourages using agile methodology rather up large size team using Scrum.
than the traditional, but the success will depend on
condition of cultural change and strategy within 4. The Proposed Solution
organization. The limitation of this work is that the A. Overview of Scrum
client must be committed to the project, has The Scrum is an agile methodology to produce a
necessary knowledge and be available to answer high quality product in short time. There are two
questions when needed (Nishijima, 2013). important concepts in Scrum; the product backlog
According to Farid et al. (2013), the agile and sprint. The product backlog represents the set of
project management methodology has not adequately requirements for the product and sprint represents an
addressed planning but prioritized activities and

444
 Life Science Journal 2014;11(8) http://www.lifesciencesite.com

iteration in which a set of activities must be done of 30 people. We divide the team into 3 teams each
(Mundra et al., 2013). having 10 people.
B. Overview of Scrum Considering that all these groups will be
There are three core roles in Scrum: PO, SM, working on the same product, there may arise some
and the ST. PO is a key stakeholder of the project and problems, for example:
is responsible to visualize and prioritize the features  Duplication of work (two teams may
list for the product The SM ensures that the Scrum implement the same part of the scope).
process is going as agreed, and prevent any  Communication failure.
impediments that can be faced by the teams e.g.  Integration of different parts of a product
communication, dependencies etc. The ST is developed by different teams.
responsible for the delivering the product at the end  Dependencies between tasks of different
of sprint. teams.
C. Large Size Team The technique that is used to solve these
A typical Scrum team has 7 members plus or problems is Scrum of Scrums meeting (Paasivaara,
minus 2. Software development projects usually are 2012).
big projects and therefore require a bigger group A. Scrum of Scrums Meeting
effort. According to Scrum, large projects need large Scrum of Scrums meetings can be consistent
team to achieve the goal in short time. But large size through an even higher level meeting called a Scrum
team in Scrum has some issues. of Scrum of Scrums. The Scrum of Scrums meeting
 Holding a daily meeting with a large size is an important technique in scaling Scrum to large
team comprising of 100 people, for example, is project teams. These meetings allow groups of teams
impractical. to discuss their work, focusing on areas of overlap
 Planning and control gets too complicated and integration.
with large size team.
 Performance of large size team is difficult to
measure.
 It is difficult for a single PO to prioritize and
sanitize a large product backlog and be ready on time
for the sprint planning meetings.

5. Scrum of Scrums
The solution for large size team of Scrum and
its issues is the “Scrum of Scrums”. In Scrum of
Scrums the Scrum team is divided into smaller teams,
which are organized hierarchically into a Scrum of
Scrums.

Figure 2. Scrum of Scrums hierarchical structure

Each team must designate one person to attend a

Scrum of Scrums meeting. Usually the person chosen
should be a technical contributor on the team like a
programmer, database administrator, designer, tester
and so on rather than a product owner or Scrum
Figure 1. Three teams from team of 30 members Master. This group then represents the ideal Scrum of
Scrums team size. In case of small number of teams
In Scrum of Scrums, we basically divide the participating in the meeting, the teams may choose 2
team into 2 or more teams, respecting the limit of 7-9 representatives; a technical contributor, as described
people per team; the Scrum of Scrums team size also above, and a Scrum Master. The attendees of the
depends on the number of teams participating. To meeting should change over the course of a project.
understand the Scrum of Scrums concept let us The team should choose its representative based on
assume this example. We have a project with a team who will be in the best position to understand and
discuss the issues that arise at that time during a

445
 Life Science Journal 2014;11(8) http://www.lifesciencesite.com

project. For example, early in a project, the issues  Team structure limitation: We may divide
that are raised at the Scrum of Scrums meeting may and organize teams into three levels: upper level,
focus on technical issues or user experience design. middle level and lower level. This structure may
Teams must send a person strong in one of these work in some project but may not work in others. It
areas. Later, if the issues are raised around how to may be more effective to divide teams on the basis of
collaborate on testing, the tester must be the person project features.
chosen for the meeting (Paasivaara, 2012).  Cross-team interaction limitation: The
B. Difference between Daily Scrum Meeting proposed methodology lacks in effective mechanisms
and Scrum of Scrums Meeting to deal with situations when there are multiple
The daily Scrum meeting is not used as a product owners or Scrum masters. A particular case
problem-solving or issue resolution meeting. Issues of this situation is when some members are working
that are raised are usually dealt with by the relevant in multiple teams.
subgroup immediately after the meeting. In the daily
Scrum meeting, each member must answer these 6. Validation
three questions: First of all, we established main goals to
 What did you do yesterday and today? validate our proposed approach. These goals are as
 What will you do today? under.
 Is there any impediment in your way? Goal 1: Optimize communication between
In Scrum of Scrums meeting one person, teams in Scrum of Scrums.
representing his or her entire team, is asked following Goal 2: Make the system work after integrating
four questions: all parts.
 What has your team done since we last met? Goal 3: Reduce the dependencies between the
 What will your team do before we meet parts of system.
again? Goal 4: Prevent the duplication of work.
 Is anything slowing the team down or For each goal, a set of meaningful questions was
getting in their way? developed that characterized it. Altogether, a
 Are you about to put something in another questionnaire consisting of 20 questions was
team’s way? distributed among IT professionals. The results were
C. Frequency for Scrum of Scrums meeting gathered, analysed and scaled using Likert scale
The frequency for Scrum of Scrums meetings (Table 1).
should be determined by the team, depending on the
Table 1. Likert scale
complexity and size of project. To make frequency of
Very low Low Nominal High Very high
Scrum meetings easier to understand, let us assume 1 2 3 4 5
that we have a project with 20 teams each having 5
people. These teams have to be grouped based on Following sections describe, in detail, the
some criteria. Let say there are 4 groups of 5 teams. findings of this survey.
Now we have 20 daily Scrum meetings, 4 daily A. Cumulative Analysis of Responses to
Scrum group meetings and 1 daily Scrum project Questions for Goal 1
meeting. Since the whole project will be divided
among 20 teams, so each team will be working on Table 2. Participants’ response to individual questions for
some features of different components of the project. goal 1
After each team finishes its work, we may face the Cumulative response to questions (%)
Question
problem of integration and configuration #
very
low nominal high
very
management. Another consideration in such low high
scenarios is testing of integrated components as a 1 20.0 32.5 37.5 10.0 0.0
system. The components may work fine when 2 0.0 0.0 32.5 50.0 17.5
executed standalone, but may not yield when 3 0.0 2.5 10.0 35.0 52.5
integrated with other components in the whole 4 0.0 2.5 7.5 40.0 50.0
5 2.5 2.5 7.5 37.5 50.0
system.
Total 22.5 40.0 95.5 172.0 170
Scrum of Scrums is a generic model that can be
Average 4.5 8.0 19.0 34.5 34.0
applied to any project, program and portfolio,
depending upon the need of the organization;
The table 2 presents participants’ response to
however, the proposed solution has few limitations
individual questions for goal 1. We found that 34%
with respect to team structure and cross-team
of the participants responded as very high and 34.5%
interaction.
responded high, whereas for only 8% the chances of

446
 Life Science Journal 2014;11(8) http://www.lifesciencesite.com

optimum communication were low. Figure 3, depicts

cumulative response to all questions for goal 1. Goal 2
Very high High Normal Low Very low
Goal 1
7% 12.5%
Very high High Normal Low Very low 0.5%
23%
4.5%
8%
34%
19%
57%

34.5% Figure 4. Average response to questions for goal 2

Table 4. Participants’ response to individual

questions for goal 3
Figure 3. Average response to questions for goal 1 Cumulative response to questions (%)
Question
very very
B. Cumulative Analysis of Responses to # low nominal high
low high
Questions for Goal 2 11 0.0 0.0 0.0 80.0 20.0
The response to survey questions corresponding 12 5.0 12.5 20.0 47.5 15.0
to goal 2 is shown in Table 3 and Figure 4. It is clear
13 27.5 32.5 35.0 5.0 0.0
from the analysis of response to our survey questions
14 32.5 35.0 22.5 10.0 0.0
6–10 that the likelihood of making system work after
15 22.5 50.0 22.50 5.0 0.0
integrating all parts is high (57%) whereas for only
few the likelihood is low (7%) (Figure 4). Total 87.5 130.0 100.0 147.5 35.0
Average 17.5 26.0 20.0 29.5 7.0
Table 3. Participants’ response to individual
questions for goal 2 D. Cumulative Analysis of Responses to
Cumulative response to questions (%) Questions for Goal 4
Question The result of survey questions for goal 4 are
very very
# low nominal high shown in Table 5. The cumulative results of
low high
questions (16-20) indicated that 32.5% of the It
6 2.5 10.0 32.50 50.00 5.00
professionals were in strong agreement (responded
7 0.00 10.0 27.50 62.50 0.00
very high) with goal 4, i.e. following the proposed
8 0.00 5.00 15.00 62.50 17.50
solution, the system will work after integration of all
9 0.00 7.50 25.00 60.00 7.50 parts. Another 24.5% responded as high, 9.5% as
10 0.00 2.50 15.00 50.00 32.50 very low, 13% as low and 20.5% as nominal. These
Total 2.5 35.0 115.0 285.0 62.5 results are summarized in Figure 6.
Average 0.5 7.0 23.0 57.0 12.5 E. Cumulative Analysis of Responses to All
Questions for all Goals
C. Cumulative Analysis of Responses to The average responses of questions for each
Questions for Goal 3 goal are shown in Table 6. The average of all the
Table 4 illustrates that questions corresponding goals depicts the overall participants’ response to the
to goal 3 retrieved 29.5% answers in agreement with proposed approach. We found that 57.9% of
high chances of reducing dependencies between the participants supported the proposed solution with
parts of system. However, 26% and 17.5% of the high (36.4%) and very high (21.5%) response.
responses appeared to be low and very low,
respectively, as shown below in Figure5

447
 Life Science Journal 2014;11(8) http://www.lifesciencesite.com

Unfortunately, the large size team is the problem in

Goal 3 classical Scrum methodology. Large teams can lead
Very high High Normal Low Very low to several serious issues including duplication of
work, communication failure, and integration of
7%
different parts and complex dependencies between
17.5% tasks done in different teams. We proposed a solution
29.5% called Scrum of Scrums to address these issues. In
Scrum of Scrums, we divided large Scrum teams into
26% teams of the right size, and organize them
hierarchically into a Scrum of Scrums. We evaluated
the proposed methodology through a survey
20% (conducted with IT professionals). The results show
that the majority of the respondents are agreed with
the effectiveness of our proposed approach.
Figure 5. Average response to questions for goal 3
Table 6. Overall participants’ response to our
questions for all goals
However, 20.6% remained neutral (responded
as nominal) and 21.5% responded as low or very low. Overall response to all goals
Goals very very
low nominal high
Table 5. Participants’ response to individual low high
questions for goal 4 1 4.5 8.0 19.0 34.5 34.0
Cumulative response to questions (%) 2 0.5 7.0 23.0 57.0 12.5
Question 3 17.5 26.0 20.0 29.5 7.0
very very
# low nominal high 4 9.5 13.0 20.5 24.5 32.5
low high
16 12.5 25.0 35.0 27.5 0.0 Total 32.0 54.0 82.5 145.5 86.0
17 2.5 5.0 20.0 50.0 22.5 Average 8.0 13.5 20.6 36.4 21.5
18 32.5 32.5 10.0 17.5 7.5
19 0.0 0.0 25.5 17.5 57.5 Average response to all goals
20 0.0 2.5 12.5 10.0 75.0
Very high High Normal Low Very low
Total 47.5 65.0 102.5 122.5 162.5
Average 9.5 13.0 20.5 24.5 32.5
8% 21.5%
13.5%

Goal 4
Very high High Normal Low Very low
20.6%

9.5% 36.4%
13% 32.5%

20.5%
Figure 7. Cumulative response to our questions for all
goals
24.5%
However, the proposed solution has few
limitations with respect to team structure and cross-
team interaction. We plan to address these limitations
Figure 6. Average response to questions for goal 4
in our future work.
7. Conclusion And Future Work
References
The computer software domain must keep pace
1. Mundra, A., Misra, S., Dhawale, C.A. Practical
with changes in the environment. Scrum
Scrum-Scrum team: Way to produce successful
methodology is excellent choice when we want to
and quality software. Computational Science
reduce the development time. Most of the software
and Its Applications (ICCSA), Ho Chi Minh
projects are large and thus require large teams.
City, Vietnam. 2013; 24-27.

448
 Life Science Journal 2014;11(8) http://www.lifesciencesite.com

2. Azham, Z. Security backlog in Scrum security Software Product Management (IWSPM). Sept.
practices. Malaysian Conference in Software 1, 2009; 1-10.
Engineering (MySEC), Malaysia, 2011; 414– 8. Harsimarjeet, S. Implementation of new
417. management Agile technique for reducing
3. Chhavi, A. Agile testing with Scrum-A survey. overtime and increasing customer satisfaction.
International Journal of Advanced Research in International Journal of Engineering Science
Computer Science and Software Engineering. and Technology (IJEST). 2011; 3:238-241.
2013; 3:452-459. 9. Nishijima, R. T. The challenge of implementing
4. Noor, T. B., Shakur, H. B., Chowdhury, M. K. Scrum Agile methodology in traditional
B., Siddique, I. M. A novel approach to development environment. International
implement burndown chart in Scrum Journal of Computers & Technology. 2013;
methodology. International Journal of 5:98-108.
Advanced Research in Computer Science and 10. Farid, W.M., Mitropoulos, F.J. NORPLAN:
Software Engineering. 2013; 2:421-427. Non-functional Requirements Planning for
5. Raghaw, C. V. S., Sharma, V., Singh, R. K. An Agile Processes. Southeastcon, 2013
experimental based study on challenges of game Proceedings of IEEE; Jacksonville, FL. 2013;1-
development with Scrum using Agile. 8.
International Journal of Advanced Research in 11. Guang-yong, Hu. Study and practice of import
Computer Science and Software Engineering. Scrum agile software development.
2012; 2:255-261. Communication Software and Networks
6. Akhtar, M. J., Ahsan, A., Sadiq, W. Z. Scrum (ICCSN), Xi'an. 2011; 217-220.
adoption, acceptance and implementation (a 12. Akif, R., Majeed, H. Issues and challenges in
case study of barriers in Pakistan's IT industry Scrum implementation. International Journal
and mandatory improvements). IEEE 17Th of Scientific & Engineering Research. 2012;
International Conference on Industrial 3:1-4.
Engineering and Engineering Management 13. Paasivaara, M., Lassenius, C., Heikkila, V.T.
(IE&EM). 29-31 Oct. 2010; 458-461. Inter-team coordination in large-scale globally
7. Vlaanderen, K., Brinkkemper, S., Jansen, S., distributed Scrum: Do Scrum-of-Scrums really
Jaspers, E. The Agile requirements refinery: work? Empirical Software Engineering and
applying Scrum principles to software product Measurement (ESEM); Lund. 2012; 235-238.
management. Third International Workshop on

5/6/2014

449