Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UK Essays.
Purpose of this thesis is to identify challenges and issues in Scrum Implementation and in proposing their solutions. This research thesis will also compare nature of issues facing by experienced and non-experienced Scrum Team. To support highlighted issues, two company’s Scrum experiences will also be concluded in this thesis. Solutions and recommendations will also be provided for highlighted issues. A tool (Excel Format) for sprint will be developed for Sprint and Product Backlog. Objective of this tool is to eliminate issues related to communication and provides statuses of tasks for better sprint management. This research thesis is divided into eight sections. Chapter-1 will provide introduction to thesis paper. This will cover introduction to Agile Development Methodology and then Scrum Framework. Drawback in Scrum Implementation and Objective of this research thesis will also be included. In Chapter-2, related work will be presented in order to provide a brief background of this research thesis. Chapter-3 will cover research methodology adopted for the thesis. In Chapter-4, data collection for this thesis is discussed. Chapter-5, identified issues and their solutions will be discussed. Chapter-6 will show backlogs for sprint management. Chapter-7 concludes this research thesis and finally in Chapter-8, list of references will be provided.
Table of Contents
Agile Development 8
Agile Methods 10
Scrum Lifecycle 11
Scrum Roles 12
Meetings in Scrum 14
Scrum Artifacts 16
Sprint – Scrum Center of Attention 16
Related Work 19
Proposed Solution 24
Research Methodology 26
Survey Data Collection 28
Identified Issues and Proposed Solutions 30
Product Backlog 37
Sprint Backlog 38
Burndown Chart 39
Appendix I 45
Appendix II 47
Agile methodology is the methodology in which things are minimally planned and are done in small increments. There is no long term planning in case of agile methodology. Iterations are short (two to four weeks) which are passed through the complete software life cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This minimizes the overall risk, and makes requirement changes adaptation for the project easy. Documentation is produced as required by stakeholders. The role of iteration is not to add more functionality but to make a release with minimum bugs at the end of the iteration. To release a product or to add new features, multiple iterations may be required. These iterations result in the minimization of the overall risk, and adaptation of the project becomes easy.
Agile is a philosophical and conceptual term to define the framework of understanding software engineering project. This method is a means of minimizing the risk by developing software in short time boxes, called iterations, each being a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration.
Agile project team hierarchy is not as strict as in other development strategies. It is usually cross-functional, that is the people in the team have different functional specialties and skills and are responsible for each phase of the project life cycle, and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members can switch roles and they are responsible for adding the tasks that deliver the functionality of iteration and they can switch their roles. The decision of how executions going to take place during iteration are taken by the team members themselves.
The agile methodology prefers face to face communication and therefore the teams are located in a single open office so as to make this communication more feasible. The face to face communication produces less documentation. The communication and collaboration is further eased by the small team size, that is, 5-20 people in one team. In the communication sessions that take place the team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. In this way the problems are exposed. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.
However, another approach may be that multiple teams work toward one common goal and might have different but important roles to play in the achievement of the final goal. This may also require a coordination of priorities across teams so as to settle the order in which each step should be taken to reach the end point of the project, keeping the most important first.
Each agile team essentially will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of every iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals.
In almost every agile methodology there is a formal meeting or face to face communication session among team members. Customer representative or any stakeholders can also attend this session but as an observer. In this communication sessions that take place the team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. In this way the problems are exposed.
Agile methods emphasize working software as the primary measure of progress. The face to face communication produces less documentation. In an agile project, documentation and other project artifacts all rank equally with working product. Stakeholders are encouraged to prioritize them with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration.
Agile software development methods have gained a good deal of popularity since the last two decades (late 1990s). These methods in comparison to more traditional approaches may offer improved outcomes for software development projects. Survey analysis disclosed that agile methods give improved outcomes from software development projects in many aspects for instance in terms of quality, satisfaction, and productivity, within approximately same cost.
Many other approaches come under this broad term. Some of the agile software development methods include:
Extreme Programming (XP)
Crystal Clear and Other Crystal Methodologies
Feature Driven Development (FDD)
Dynamic Systems Development Method (DSDM)
Scrum is an approach for managing a development process not only for software development. It does not give an account of technical development activities.
Actually Scrum itself is a management method and not an engineering method. However, it is well-matched with any engineering approach that can be applied in monthly iterations. Often, Scrum is combined with XP practices. Scrum replaces and expands the planning game
Scrum’s goal is facilitating the self-organization of the team so that it can adapt to the specifics of the project and their changes over the period of time.
Scrum is also known as “process skeleton”, which comprises sets of practices and roles that are predefined. Scrum is a method that teams can take up promptly for planning and management. Each step has an ample account on planning, designing, building up and test code at the same time of following team progress. The main advantage of scrum is that, it is plain and simple to follow.
Typically the duration of a sprint is two to four weeks and this time length is decided by the team. During the given time period, a team generates shippable product increment in general (for example, working and tested software). The set of specifications that go into a sprint develop from the product “backlog,” which is a preexistent set of high level requirements of work to be done. The backlog items which are involved in the sprint are decided during the sprint planning meeting. In this meeting, the product owner tells the team about his requirements and the items in the product backlog he wants completed. Then the team estimates, how much of the given tasks they can accomplish during the next sprint. During a sprint, no one can change the sprint backlog which implies that the requirements are fixed for that sprint. After the completion of the sprint, the team gives demo on the usage of the software.
Scrum allows the formations of teams that are self-organized by supporting co-location of members and encouraging verbal communication across all team members and moreover disciplines that are involved in the project.
There are a number of implementations of systems for managing the Scrum process ranging from yellow stickers and whiteboards, to software packages. One of Scrum’s leading advantages is that it is very easy to learn and needs little effort to start using.
As earlier discussed, the intent of Scrum is to build working components in small iterations, each iteration lasting between two and four weeks. A typical Scrum lifecycle has the following steps:
Write the requirements (and store in the Backlog)
Plan the release (which could span more than one 2-4 week Sprint)
Plan the Sprint
Conduct the Sprint
Conduct Sprint retrospective
Daily stand-up meetings are held to track team progress and identify barriers.
Fig. 1: Scrum Process – Courtesy of 
An important rule in scrum is its recognition that during a project the customers can change their minds and requirements about what they want and need; this change is often called as requirements churn. These unpredicted challenges cannot be easily addressed in a conventional predictive or planned manner. Scrum takes up an empirical approach by agreeing that the problem cannot be completely understood or defined. Instead, focus should be on maximizing the team’s ability to deliver quickly and respond to emerging requirements.
There are two categories of roles present in Scrum i.e. “Pig Role” and “Chicken Role”.
The Pigs are the ones who are dedicated to the project in the Scrum process. Pigs are the ones with “their bacon on the line” and doing all the actual work of the project. There are further three main categorizations of Pig Roles are;
The Product Owner stands for the voice of the customer. He is the person who represents all customers and at the same time manages the Product Backlog Sets priorities. He is the person who stands for the group of stakeholders. He makes sure that the Scrum Team works with the “right things” from a business point of view. A Product Owner can be a member of the Scrum Team but he cannot be a Scrum Master.
According to original Scrum, Product Owner falls in the category of “pig”. However, if his involvement is not on regular basis then he/she may be considered as a “chicken”. A product owner also selects requirements for a Sprint.
Scrum is aided by a Scrum Master. The primary job of the Scrum Master is to remove obstructions to the ability of the team to deliver the sprint goal and thus responsible to make sure a smooth execution of the scrum process. He is the one who is responsible for managing all the processes, normally in place of a project manager. As the team is self-organizing, Scrum Masters doesn’t play the role as that of a leader but he acts as a buffer between the team and any distracting influences. For this, he acts as a teacher and coach and not as a manager. The Scrum Master makes sure that the Scrum process is used as planned and also acts as the enforcer of rules. The most crucial part of the role of Scrum Master is to protect the team and maintain their focus on the tasks in hand. The role of a Scrum Master targets both Team and Product Owner accountable for removing organizational hindrances. Moreover, Master and Team together are in charge for product delivery.
The team is responsible for the delivery of the product. A team typically has 5-9 members and acts as a cross-functional group. The team does all the actual work like analysis, designing, testing, implementation and technical communication, etc. The developers are analyzed as a self-organizing group of technical and process experts. It is also noteworthy that the role is of team and not of a developer.
Larger projects can use multiple teams for their completion.
At times, the Scrum Master also acts as a Product Owner or Team member too depending on the situation. This also generates conflict but that is resolvable.
These are not component of the actual Scrum process, but must be taken into account. Chickens are the one for whom the software is being built.
Stakeholders (customers, vendors)
Stakeholders are only directly involved in the process during the sprint reviews. These are the one who enable the project and for whom the project will produce the agreed-upon profit, which justify creation of the project.
Managers are the people who set up the environment for the product development organizations.
Meetings in Scrum
During the sprint, a project status meeting occurs on daily basis. It is called a “daily scrum”, or “the daily standup”. The specific agenda of these meetings are:
The meeting starts exactly on time.
All are welcome, but only “pigs” got the right to speak.
The meeting is restricted to 15 minutes
The meeting should be conducted at the same location and same time daily
During the meeting, every team member answers three questions, these are:
What is your progress since yesterday?
What is your today’s plan?
Is there any problems hindering you from achieving your goal?
Scrum of Scrums
Scrum of Scrums also occurs on daily basis, each day normally after the daily scrum.
These meetings permit groups of teams to talk about their work, specially focusing on areas of overlapping and integration.
An elected person from each team attends these meetings.
The guidelines remain the same as of the Daily Scrum including the following four questions:
What has your team done since the last meeting?
What will your team do before the next meeting?
Is there anything obstructing your team progress?
Are you about to put something in another team’s way?
Sprint Planning Meeting
A “Sprint Planning Meeting” is conducted at the beginning of the sprint cycle (every 7-30 days). This meeting purpose is to:
Identify what is to be completed
Prepare the Sprint Backlog that gives an account of the time it will take to do that work, with the whole team
Identify and communicate how much of the work is likely to be done during the current sprint
Eight hour limit
Two meetings are held at the end of a sprint cycle, these are called the “Sprint Review Meeting” and the “Sprint Retrospective”
Sprint Review Meeting
Analyze the work that was done and not done.
Present the completed work to the stakeholders in the form of a demo.
Incomplete work cannot be demonstrated
Four hour time limit
All team members reflect on the past sprint
Make continuous process developments
Two main questions are asked in the sprint retrospective: What worked well during the sprint? What improvements can be made in the next sprint?
Three hour time limit
It is a high-level document for the whole project. It includes backlog items like broad descriptions of all necessary specifications, wish-list items, etc. prioritized by business value. It answers the “What” that will be built. It is open and can be edited by anyone and contains rough estimates of both business value and development effort. Those estimates enables the Product Owner to determine the timeline and, to a limited extent, priority.
The Product Owner possesses and owns the product backlog. Business value is set by the Product Owner while the development effort is set by the Team.
This document contains the information regarding the implement the features for the upcoming sprint by the team. Features are broken down into small tasks for feasibility. These tasks are normally estimated between four and sixteen hours of work.
With all these details the whole team understands exactly what is to be done, and anyone can potentially take up a task from the list. Tasks on the sprint backlog are not assigned. They are in fact signed up for by the team members as desired, according to the set priority and the team member expertise.
The sprint backlog is the property of the Team and the team sets the estimations.
Burn Down Chart
It is a chart that is displayed publicly to show the remaining work in the sprint backlog. The burn down chart is updated on daily basis and gives a simple view of the sprint progress. It also gives a quick account of reference. There are also other types of burn down, for instance the Release Burn down Chart which depicts the amount of work left to accomplish the target commitment for a Product Release (normally spanning through multiple iterations) .the other one is Alternative Release Burn down Chart, which basically serves for the same, but clearly shows scope changes to Release Content, by resetting the baseline.
Sprint – Scrum Center of Attention
During a Sprint, requirements are set in advance but the process it not. Daily scrum may adapt anything as needed or required.
Numerous works have been done to cover all aspects of Scrum framework but still there are open research areas which need to be covered. In every agile development methodology, we are taking here Scrum Framework for research; there are some limitations with respect to nature of work . Some issues are highlighted in  such as training, management, involvement, access to external resources, corporate or organization size and  for distributed area, sub contraction, developing large and complex systems, but still there are open areas where no significant research work has been done. According to , following areas of limitations in agile processes: distributed environments, building reusable artifacts, large teams, and developing safety-critical software.
Agile methods have been projected as a means for early and speedy production of working software. Supporters of agile processes argue that the source code is the most crucial deliverable and that it should take preference over analysis, design, and documentation. On the contrary, critics refer to the notion of “corporate memory loss” which could be caused if there is little emphasis on producing good design models and documents, especially in case of large complex software based on empirical analysis, experience reports, and researching the agile manifesto.
Objective of this thesis is to minimize the issues and challenges of Scrum in Software Development and propose solutions to some of them.
In this section, related work will be presented in order to provide a brief background of this research thesis.
Jeffrey A. Livermore (2008): Author’s research was based on identifying factors related to agile software development methodologies implementation. The research showed that there are a number of factors under management’s control that effects execution of an agile Software Development Methodology. The factors that affect the sound execution of an agile SDM are training on the methodology, active management involvement and support, access to external resources, and company size. While, successful execution is not hampered by applying a complete methodology implementation strategy and development team collocation. At the same time using models and templates, developing software whether for Internet or intranet usage doesn’t affect successful implementation too. These factors were identified from online survey result conducted by author.
Artem Marchenko, Pekka Abrahamsson (2008): This is a case study performed by author on a Scrum Team having size of 20 members. Scrum Team was working on simultaneous multi-project R&D environment. In this research paper author examined Multi-Project Environment and determined challenges emerge in adoption of Scrum. Author’s research question, (How can Scrum be used in a multi-team and multi-project environment and what challenges, if any, emerge from the empirical qualitative evidence?), was answered by empirical evidence obtained from empirical observations results for challenges in the adoption process of Scrum Author highlighted 10 challenges and contends that these results carry great significance for other industrial teams. Highlighted issues are listed below
Overemphasis on the Scrum process and practices
Scrum Master ignoring the process
Lack of clear management, expectations and actions
High rate of bug fixing and maintenance
Fitting Scrum and short iterations into research intensive teamwork
Over specialism undermining collaboration
Committing to too much
Difficulty in tracking progress and in using the results of the tracking
Management interfering too much
Juyun Cho (2008): In this research thesis, author differentiates between traditional software development methods and agile software development methods. Author then define characteristics of Scrum framework and then finally mentioned issues and challenges discovered through a case study of a company which has employed Scrum for many projects.
The paper also introduced the roles, ceremonies, and artifacts of Scrum, which is considered one of the most famous agile software development methods in the industry. Moreover, the paper also shows the five issues and challenges including documentation, communication, user involvement, working environment, and Scrum ceremonies, found through an in-depth case study in a software company which develops small- and mid-size web-based applications. If all the five issues and challenges are taken into consideration and resolved before launching the project, organizations will face low difficulty level in creating high-quality software products using Scrum.
Steve Berczuk (2007): Author stated that in agile development methodology, communication is the main reason for successful agile implementation where teams are distributed. Distribution reduces communication bandwidth but the rule of agile methods serve to increase communication and feedback hence distribution causes non-compliance with agile methodology.
Agile processes rely on feedback and communication to continue working and they often perform best with co-located teams for the same reason. At time, agile makes sense because of project requirements and a distributed team makes sense because of resource constraints. A distributed team can be dynamic and fun to work on if the team takes an active role in overcoming the hurdles that arise due to distribution.
It is difficult to do agile with distributed teams because distribution can decrease communication bandwidth. Co-located teams that do not have sufficient communication can also fail with agile methods.
But the rules of agile methods provide to high level of communication and feedback. Any team is best served by following the rules of the agile method with very few adjustments. Distribution increases the harm that non-compliance can cause. A team can be successful and overcome obstacles if it feels like it owns the process and the tools.
Aniket Mahanti (2006): This survey thesis accounts on the main challenges faced by the enterprises in implementing agile practices. Gathering information from the literature issues like framework for agile organizational change and adoption strategies are analyzed (or scrutinized). Inputs from the industry shows that most organizations are best fitted in implementing a combination of traditional and agile methods.
Extensive implementation of agile practices by the software industry has inhibited a number of challenges. The recognition of dynamics of organizational change helps in the successful execution of new methodologies. The question of agile practices crossing the chasm is open.
If the academic world considers this methodology to be helpful and introduces relevant courses at the university-level then it can be said that the upcoming generation of software professionals may show more acceptance to the concept of agility. It may take years to implement it and it is quite possible that during this other promising and advanced technologies may come up and surpass the agility paradigm.
The author pinpoints 4 issues in paper which identify from his survey. These are:
Limited support for distributed environments
Limited support for building reusable artifacts
Limited support for development involving large teams
Limited support for developing safety-critical software
Andrew Begel, Nachiappan Nagappan (2006): This thesis accounts on the results of an empirical study, which was taken at Microsoft. The aim of that study was to learn about agile development and how it is perceived by the people in development, testing, and management. It was observed that one-third of them were using agile methodologies to varying degrees and most of them found it quite helpful due to improved communication between team members, quick releases and the increased flexibility of Agile designs.
On the other side, developers are anxious about scaling Agile to larger projects (more than 20-30 members). Excessive meetings add too much overhead on developers and hence results in difficulty in adoption of Agile Software Development methods.
Barry Boehm, Richard Turner (2005): Boehm and Turner’s discussions with traditional developers and managers relating to agile software development practices almost always comprised two somewhat conflicting ideas. They discovered that on small, stand-alone projects, agile practices are less heavy and more adjustable with the software industry’s rapidly increasing needs for quick development and dealing with continuous change.
Outi Salo (2004): In this thesis empirical results are presented where team conducted Post-Iteration-Workshop after the completion of two XP (Extreme Programming) projects to improve and optimize working methods. After all process iterations for the enhancement and optimized working methods, a “post-iteration workshops were conducted out by project teams. These two empirical results from two XP (Extreme Programming) projects is being reported in this paper.
The paper supplies an account of both qualitative and quantitative data from the total of eight post-iteration workshops. Therefore, it helps in the estimation and contrasts the findings of the two projects.
The result depicts both merits and demerits of the findings. Simultaneously it gives the variation of negative findings and improvement process actions towards the end of both projects. The data collected after post-iteration workshops showed level of confidence and learning by project teams
Main idea of this thesis is to identify unidentified challenges and issues in Scrum implementation and devise techniques to tackle those issues. However this thesis will also propose solutions to issues and challenges mentioned in  such as documentation, communication, user involvement, working environment, scrum ceremonies and client involvement . For problems related to sprint management, a tool/pattern is devised for Sprint and Product Backlog. Objective of this tool is to eliminate issues related to communication and sprint management. This tool also helps in meeting sprint objectives and in case of any failure it will show where and why team fails.
This research thesis covers formal sessions with two organizations to highlight and compare nature of issues they faced in scrum implementation in development. These two organizations are “Bentley Systems Pakistan” and “Digital Prodigy Limited”. Former has more than 3 years and later has 9 months experience in implementation of scrum framework. This experience gap will allow comparing nature of issues facing by experienced and non-experienced Scrum Team.
Several approaches are used to conduct any research such as Quantitative, Qualitative or Mixed approach. Mixed Approach is used to identify and highlight Issues and Challenges of Scrum Implementation with the help of existing work and from experiences of two companies by survey.
Questions in the survey are drawn from self Scrum Implementation experience. Survey instrument was reviewed peers for readability and then by other Scrum experts for content validity. Survey was distributed to different Scrum experts for more than two weeks.
For this research thesis, data were collected from two sources i.e. survey and face to face interview with 20 employees from two companies including project managers, scrum masters, development team and quality assurance team.
Survey Data Collection
Survey Data Collection
There were 35 individuals who received an invitation to participate in the survey. Out of them there were 20 responses which were received hence making return rate of 57.14%. Survey included 23 questions and no incentive was offered to any individual to complete and submit.
Individual experiences ranged from 1 year to 15 years. All of the interviews were audio taped, write out and then coded. Surveys data were stored in database and later performed data mining on them. In the process of data analysis grounded theories were used to derive constructs from collected raw data. Data were also passed through data mining process to find out relations between different constructs.
If you need assistance with writing your essay, our professional essay writing service is here to help!Find out more
Cite This Work
To export a reference to this article please select a referencing style below:
Related ServicesView all
DMCA / Removal Request
If you are the original writer of this essay and no longer wish to have the essay published on the UK Essays website then please: