Purpose of the thesis is to recognize problems and issues in Scrum Implementation and in proposing their solutions. This research thesis will also compare mother nature of issues facing by experienced and non-experienced Scrum Team. To aid highlighted issues, two company's Scrum activities will also be concluded in this thesis. Solutions and recommendations may 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 split into eight sections. Chapter-1 provides benefits to thesis paper. This will cover advantages to Agile Development Methodology and then Scrum Platform. Disadvantage in Scrum Implementation and Objective of this research thesis will also be included. In Chapter-2, related work will be shown to be able to give a brief background of this research thesis. Chapter-3 will cover research methodology implemented for the thesis. In Section-4, data collection for this thesis is discussed. Chapter-5, discovered issues and their solutions will be reviewed. Section-6 will show backlogs for sprint management. Chapter-7 concludes this research thesis and lastly in Section-8, list of recommendations will be provided.
Table of Contents
Acknowledgement 2
Abstract 4
6
Introduction 8
Agile Development 8
Agile Methods 10
Scrum 10
Scrum Lifecycle 11
Scrum Functions 12
Meetings in Scrum 14
Scrum Artifacts 16
Sprint - Scrum Centre of Attention 16
Drawback 17
Objective 17
Related Work 19
Proposed Solution 24
Research Technique 26
Survey Data Collection 28
Identified Issues and Proposed Alternatives 30
Backlogs 37
Product Backlog 37
Sprint Backlog 38
Burndown Graph 39
Conclusion 41
References 43
Appendixes 45
Appendix I 45
Appendix II 47
CHAPTER 1
Introduction
Agile Development
Agile technique is the strategy where things are minimally designed and are done in small increments. There is absolutely no long-term planning in case there is agile technique. Iterations are brief (two to a month) which are passed through the complete software life routine, including planning, requirements analysis, design, coding, device testing, and approval testing when a working product is proven to stakeholders. This minimizes the overall risk, and makes necessity changes version for the task easy. Paperwork is produced as required by stakeholders. The role of iteration is not to add more operation but to produce a release with minimum bugs by the end of the iteration. Release a a product or even to add new features, multiple iterations may be needed. These iterations bring about the minimization of the overall risk, and adaptation of the project becomes easy.
Agile is a philosophical and conceptual term to establish the framework of understanding software anatomist project. This method is a way of minimizing the risk by producing software in a nutshell time bins, called iterations, each being a miniature software task of its, and includes every one of the tasks necessary to release the mini-increment of new operation: planning, requirements evaluation, design, coding, trials, and documents. While an iteration might not exactly add enough operation to warrant releasing the product, an agile software job intends to be capable of launching new software by the end of every iteration.
Agile job team hierarchy is not as strict just as other development strategies. It is usually cross-functional, that is the people in the team have different functional specialties and skills and are sensible for each stage of the project life circuit, and self-organizing without awareness for just about any existing corporate and business hierarchy or the corporate roles of associates. Team members can switch functions and they're accountable for adding the tasks that deliver the features of iteration and they can change their roles. Your choice of how executions heading to take place during iteration are taken by the associates themselves.
The agile technique prefers in person communication and then the teams are found in a single open office to be able to make this communication more possible. The face to handle communication produces less documents. 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 associates report to each other what they performed yesterday, what they plan to do today, and what their roadblocks are. In this manner the problems are exposed. Much larger development initiatives may be supplied by multiple groups working toward the goal or different parts of an effort. This may also require a coordination of priorities across clubs.
However, another approach may be that multiple clubs work toward one common goal and might have different but important jobs to learn in the accomplishment of the final goal. This may also require a coordination of priorities across teams in order to settle the order where each step should be taken to reach the end point of the task, keeping the most crucial first.
Each agile team essentially will include a customer rep. This person is appointed by stakeholders to do something with the person and makes a personal commitment to being available for creators to answer mid-iteration problem-domain questions. By the end of every iteration, stakeholders and the client representative review improvement and re-evaluate priorities with a view to optimizing the profits on return and ensuring positioning with customer needs and company goals.
In nearly every agile methodology there's a formal reaching or in person communication procedure among associates. Customer representative or any stakeholders can also show up at this session but as an observer. With this communication sessions that happen the team members report to the other person what they does last night, what they plan to do today, and what their roadblocks are. In this way the issues are revealed.
Agile methods point out working software as the primary measure of progress. The face to handle communication produces less documentation. Within an agile project, documentation and other project artifacts all ranking evenly with working product. Stakeholders are encouraged to prioritize them with other iteration outcomes based solely on business value perceived at the start of the iteration.
Agile software development methods have gained a good deal of popularity because the last two decades (overdue 1990s). These procedures compared to more traditional methods may offer better benefits for software development projects. Survey evaluation disclosed that agile methods give improved upon outcomes from software development tasks in many aspects for example in terms of quality, satisfaction, and production, within about same cost.
Agile Methods
Many other methods come under this broad term. A number of the agile software development methods include:
Extreme Coding (XP)
Crystal Clear and Other Crystal Methodologies
Feature Motivated Development (FDD)
Pragmatic Programming
Dynamic Systems Development Method (DSDM)
Scrum
Scrum is an approach for owning a development process not limited to software development. It generally does not give an account of complex development activities.
Actually Scrum itself is a management method rather than an anatomist method. However, it is well-matched with any engineering approach that can be applied in regular iterations. Often, Scrum is coupled with XP routines. 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 time of your time.
Scrum is also called "process skeleton", which includes sets of procedures and tasks that are predefined. Scrum is a method that teams may take up promptly for planning and management. Each step comes with an ample profile on planning, developing, building up and test code at the same time of following team progress. The main good thing about scrum is the fact, it is plain and simple to check out.
Typically the length of a sprint is two to four weeks and this time length is set by the team. During the given time period, a team produces shippable product increment on the whole (for example, working and analyzed software). The set of specifications that get into a sprint develop from the product "backlog, " which is a preexistent set of higher level requirements of work to be done. The backlog items which get excited about the sprint are determined during the sprint planning meeting. In this reaching, the product owner says the team about his requirements and the things in the product backlog he wants completed. Then the team quotes, how much of the given jobs they can accomplish through the next sprint. Throughout a sprint, no-one can transform the sprint backlog which implies that certain requirements are fixed for this sprint. Following the conclusion of the sprint, the team offers demo on the use of the program.
Scrum allows the formations of groups that are self-organized by helping co-location of users and encouraging verbal communication across all associates and additionally disciplines that are involved in the task.
There are a number of implementations of systems for handling the Scrum process ranging from yellow stickers and whiteboards, to software packages. Among Scrum's leading advantages is that it is super easy to learn and needs little effort to start using.
Scrum Lifecycle
As earlier mentioned, the intention of Scrum is to develop working components in small iterations, each iteration lasting between two and four weeks. An average Scrum lifecycle has the following steps:
Write certain requirements (and store in the Backlog)
Plan the release (which could span several 2-4 week Sprint)
Plan the Sprint
Conduct the Sprint
Analysis
Design
Coding
Testing
Conduct Sprint retrospective
Daily stand-up meetings are organised to keep track of team progress and identify obstacles.
Fig. 1: Scrum Process - Thanks to [4]
An important rule in scrum is its acceptance that during a project the customers can transform their thoughts and requirements in what they want and need; this change is often called as requirements churn. These unpredicted issues cannot be easily addressed in a typical predictive or planned manner. Scrum takes up an empirical methodology by agreeing that the situation cannot be completely known or defined. Instead, focus should be on increasing the team's capability to provide quickly and respond to emerging requirements.
Scrum Roles
There are two types of roles present in Scrum i. e. "Pig Role" and "Chicken Role".
Pig Roles
The Pigs are the ones who focus on the task 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;
Product Owner
The VENDOR stands for the tone of voice of the customer. He is the individual who symbolizes all customers and at the same time manages the Product Backlog Packages priorities. He's the individual who means the band of stakeholders. He makes sure that the Scrum Team works together with the "right things" from an enterprise point of view. SOMETHING Owner can be a member of the Scrum Team but he cannot be a Scrum Grasp.
According to original Scrum, VENDOR falls in the category of "pig". However, if his engagement is not on regular basis then he/she may be considered as a "chicken". Something owner also selects requirements for a Sprint.
Scrum Master
Scrum is aided by the Scrum Master. The principal job of the Scrum Master is to remove obstructions to the ability of the team to provide the sprint goal and so responsible to be sure a even execution of the scrum process. He's the one who's responsible for controlling all the techniques, normally instead of a project administrator. 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 your team and any distracting influences. Because of this, he operates as a teacher and coach rather than as a administrator. The Scrum Get better at makes certain that the Scrum process is utilized as designed and also serves as the enforcer of rules. The most crucial part of the role of Scrum Professional is to safeguard the team and maintain their focus on the tasks at hand. The role of an Scrum Master focuses on both Team and Product Owner accountable for eliminating organizational hindrances. In addition, Professional and Team alongside one another are in charge for product delivery.
Team
The team is responsible for the delivery of the merchandise. A team typically has 5-9 associates and works as a cross-functional group. The team does indeed all the genuine work like evaluation, designing, testing, execution and technological communication, etc. The designers are analyzed as a self-organizing group of technical and process experts. It is also noteworthy that the role is of team rather than of a creator.
Larger projects may use multiple teams for his or her completion.
At times, the Scrum Grasp also operates as a Product Owner or Team member too depending on situation. This also produces discord but that is resolvable.
Chicken Roles
These are not element of the real Scrum process, but must be taken into account. Hens are the one for whom the program is being built.
Stakeholders (customers, vendors)
Stakeholders are only directly mixed up in process through the sprint reviews. These are the one who permit the project and then for whom the job will produce the agreed-upon earnings, which justify creation of the job.
Managers
Managers will be the people who set up the environment for the merchandise development organizations.
Meetings in Scrum
Daily Scrum
During the sprint, a task status reaching occurs on daily basis. It is called a "daily scrum", or "the daily standup". The specific agenda of the meetings are:
The meeting starts exactly promptly.
All are pleasant, but only "pigs" received the to speak.
The meeting is restricted to 15 minutes
The appointment should be conducted at the same location and same time daily
During the getting together with, every team member answers three questions, they are:
What is your improvement since last night?
What is your today's plan?
Is there any problems hindering you from reaching your goal?
Scrum of Scrums
Scrum of Scrums also occurs on daily basis, everyday normally following the daily scrum.
These meetings allow groups of groups to talk about their work, specially concentrating on regions of overlapping and integration.
An elected person from each team attends these meetings.
The guidelines remain the same as of the Daily Scrum like the following four questions:
What has your team done because the last reaching?
What will your team do prior to the next meeting?
Is there anything obstructing your team improvement?
Are you going 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 appointment goal is to:
Identify what is to be completed
Prepare the Sprint Backlog that gives an account of the time it will require to achieve that work, with the whole team
Identify and speak how much of the work is likely to be done during the current sprint
Eight hour limit
Two meetings are held by the end of an sprint cycle, they are called the "Sprint Review Reaching" and the "Sprint Retrospective"
Sprint Review Meeting
Analyze the work that was done rather than done.
Present the completed work to the stakeholders in the form of a demonstration.
Incomplete work can't be demonstrated
Four hour time limit
Sprint Retrospective
All associates reflect on days gone by sprint
Make continuous process developments
Two main questions are asked in the sprint retrospective: What functioned well during the sprint? What improvements can be produced within the next sprint?
Three hour time limit
Scrum Artifacts
Product Backlog
It is a high-level record for your project. It includes backlog stuff like broad descriptions of all necessary technical specs, wish-list items, etc. prioritized by business value. It answers the "What" which will be built. It really is open up and can be edited by anyone possesses rough quotes of both business value and development effort. Those estimates enables the merchandise Owner to look for the timeline and, to a limited extent, goal.
The Product Owner possesses and has the merchandise backlog. Business value is set by the merchandise Owner while the development effort is defined by the Team.
Sprint Backlog
This document provides the information regarding the use the features for the approaching sprint by the team. Features are broken down into small duties for feasibility. These duties are normally believed between four and sixteen hours of work.
With each one of these details the whole team understands exactly what is usually to be done, and anyone could take up an activity from the list. Duties on the sprint backlog aren't assigned. They are in fact signed up for by the team members as desired, according to the set concern and the team member skills.
The sprint backlog is the property of the Team and the team places the estimations.
Burn Down Chart
It is a graph that is viewed publicly to show the rest of the work in the sprint backlog. The shed down chart is updated on daily basis and provides a straightforward view of the sprint improvement. It also gives a quick bill of reference. There are also other types of shed down, for example the Release Burn off down Chart which depicts the amount of work left to accomplish the target determination for a Product Release (normally spanning through multiple iterations). the other an example may be Alternative Release Burn down Chart, which basically functions for the same, but clearly shows opportunity changes to Release Content, by resetting the baseline.
Sprint - Scrum Centre of Attention
During a Sprint, requirements are occur advance however the process it not. Daily scrum may modify anything as needed or required.
Drawback
Numerous works have been done to cover all aspects of Scrum framework but nonetheless there are wide open research areas which need to be covered. In every agile development strategy, we could taking here Scrum Platform for research; there are a few limitations with respect to character of work [5]. Some issues are outlined in [5] such as training, management, engagement, access to exterior resources, commercial or business size and [9] for distributed area, sub contraction, expanding large and sophisticated systems, but nonetheless there are wide open areas where no significant research work has been done. Matching to [2], following areas of limits in agile techniques: distributed environments, building reusable artifacts, large teams, and growing safety-critical software.
Objective
Agile methods have been projected as a means for early on and speedy development of working software. Followers of agile techniques argue that the source code is the most crucial deliverable and that it should take choice over evaluation, design, and documents. On the contrary, critics make reference to the notion of "corporate memory reduction" which could be caused if there is little emphasis on producing good design models and documents, especially in case of large complicated software based on empirical evaluation, experience studies, and exploring the agile manifesto[2].
Objective of the thesis is to reduce the problems and troubles of Scrum in Software Development and propose solutions to a few of them.
CHAPTER 2
Related Work
In this section, related work will be presented in order to provide a brief background of the research thesis.
Jeffrey A. Livermore (2008): Author's research was based on identifying factors related to agile software development methodologies execution. The research confirmed that there are a number of factors under management's control that results execution of an agile Software Development Methodology. The factors that influence the reasonable execution of agile SDM are training on the strategy, active management involvement and support, usage of external resources, and company size. While, successful execution is not hampered through the use of a complete methodology execution strategy and development team collocation. At the same time using models and web templates, developing software whether for Internet or intranet usage doesn't affect successful implementation too. These factors were determined from paid survey end result conducted by author.
Artem Marchenko, Pekka Abrahamsson (2008): This is a research study performed by publisher over a Scrum Team having size of 20 people. Scrum Team was focusing on simultaneous multi-project R&D environment. Within this research paper author reviewed Multi-Project Environment and determined problems emerge in adoption of Scrum. Author's research question, (How can Scrum be utilized in a multi-team and multi-project environment and what issues, if any, emerge from the empirical qualitative proof?), was replied by empirical facts obtained from empirical observations results for problems in the adoption process of Scrum Author highlighted 10 problems and contends that these results hold great significance for other commercial teams. Highlighted issues are posted below
Overemphasis on the Scrum process and practices
Scrum Master ignoring the process
Lack of clear management, expectations and actions
High rate of bug mending and maintenance
Fitting Scrum and short iterations into research extensive teamwork
Over specialism undermining collaboration
Over individualism
Committing to too much
Difficulty in traffic monitoring improvement and in using the results of the tracking
Management interfering too much
Juyun Cho (2008): In such a research thesis, creator differentiates between traditional software development methods and agile software development methods. Author then identify characteristics of Scrum platform and then finally brought up issues and problems discovered via a case study of your company which includes employed Scrum for most projects.
The paper also presented the roles, ceremonies, and artifacts of Scrum, which is known as one of the very most famous agile software development methods on the market. Moreover, the paper also shows the five issues and problems including documentation, communication, user participation, working environment, and Scrum ceremonies, found via an in-depth research study in a software company which develops small- and mid-size web-based applications. If all the five issues and troubles are taken into consideration and fixed before launching the job, organizations will face low difficulty level in creating high-quality software products using Scrum.
Steve Berczuk (2007): Author stated that in agile development technique, communication is the main reason behind successful agile execution where teams are sent out. Circulation reduces communication bandwidth however the rule of agile methods provide to increase communication and feedback hence syndication causes non-compliance with agile technique.
Agile processes count on feedback and communication to keep working plus they often perform best with co-located teams for the same reason. At time, agile makes sense because of job requirements and a distributed team is practical because of reference constraints. A distributed team can be strong and fun to focus on if the team can take an active role in conquering the hurdles that come up due to syndication.
It is difficult to do agile with distributed teams because syndication can lower communication bandwidth. Co-located teams that don't have sufficient communication can also fail with agile methods.
But the guidelines of agile methods provide to advanced of communication and opinions. Any team is most beneficial served by following rules of the agile method with hardly any adjustments. Distribution increases the injury that non-compliance can cause. A team can be successful and overcome hurdles if it feels like it owns the process and the tools.
Aniket Mahanti (2006): This study thesis accounts on the main challenges faced by the enterprises in implementing agile routines. Gathering information from the literature issues like framework for agile organizational change and adoption strategies are examined (or scrutinized). Inputs from the industry shows that most organizations are best built in implementing a combination of traditional and agile methods.
Extensive execution of agile tactics by the software industry has inhibited lots of difficulties. The acknowledgement of dynamics of organizational change helps in the successful execution of new methodologies. The question of agile tactics crossing the chasm is open up.
If the academic world considers this methodology to be helpful and introduces relevant classes at the university-level then it could be said that the future generation of software specialists may show more approval to the idea of agility. It might take years to put into action it and it is quite possible that in this other promising and advanced solutions may come up and exceed the agility paradigm.
The author pinpoints 4 issues in newspaper which identify from his study. They are:
Limited support for sent out environments
Limited support for building reusable artifacts
Limited support for development regarding large teams
Limited support for producing safety-critical software
Andrew Begel, Nachiappan Nagappan (2006): This thesis accounts on the results of any empirical study, which was taken at Microsoft. The purpose of that analysis was to find out about agile development and exactly how it is perceived by folks in development, testing, and management. It had been witnessed that one-third of them were using agile methodologies to differing degrees and almost all of them found it quite helpful anticipated to much better communication between team members, quick produces and the increased flexibility of Agile designs.
On the other area, developers are anxious about scaling Agile to bigger projects (more than 20-30 customers). Excessive conferences add too much over head on developers and hence results in difficulty in adoption of Agile Software Development methods.
Barry Boehm, Richard Turner (2005): Boehm and Turner's conversations with traditional designers and managers relating to agile software development practices more often than not comprised two slightly conflicting ideas. They learned that on small, stand-alone assignments, agile methods are less heavy and even more adjustable with the program industry's rapidly increasing needs for quick development and interacting with ongoing change.
Outi Salo (2004): With this thesis empirical email address details are provided where team conducted Post-Iteration-Workshop following the conclusion of two XP (Extreme Programming) projects to improve and enhance working methods. In the end process iterations for the improvement and optimized working methods, a "post-iteration workshops were conducted out by job teams. These two empirical results from two XP (Extreme Encoding) projects is being reported in this paper.
The paper supplies a merchant account of both qualitative and quantitative data from the total of eight post-iteration workshops. Therefore, it can help in the estimation and contrasts the findings of the two projects.
The effect depicts both merits and demerits of the results. Simultaneously it gives the variance of negative results and improvement process actions towards the finish of both jobs. The data collected after post-iteration workshops exhibited level of assurance and learning by project teams
CHAPTER 3
Proposed Solution
Main idea of this thesis is to identify unidentified issues and issues in Scrum implementation and devise ways to tackle those issues. However this thesis will also propose solutions to issues and troubles mentioned in [9] such as documentation, communication, user participation, working environment, scrum ceremonies and client engagement [5]. For problems related to sprint management, a tool/style is devised for Sprint and Product Backlog. Objective of the tool is to eliminate issues related to communication and sprint management. This tool also helps in reaching sprint goals and in case there is any failure it will show where and why team fails.
This research thesis protects formal trainings with two organizations to highlight and compare nature of issues they experienced in scrum execution in development. Both of these organizations are "Bentley Systems Pakistan" and "Digital Prodigy Limited". Ex - has more than three years and later has 9 weeks experience in execution of scrum framework. This experience gap will allow checking aspect of issues facing by experienced and non-experienced Scrum Team.
CHAPTER 4
Research Methodology
Several approaches are used to perform any research such as Quantitative, Qualitative or Blended approach. Mixed Way is used to identify and highlight Issues and Obstacles of Scrum Execution with the help of existing work and from activities of two companies by survey.
Questions in the study are attracted from do it yourself Scrum Implementation experience. Survey instrument was researched 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 gathered from two resources i. e. review and in person interview with 20 employees from two companies including job managers, scrum experts, development team and quality confidence team.
CHAPTER 5
Survey Data Collection
There were 35 those who received an invitation to participate in the review. Out of them there were 20 responses that have been received hence making go back rate of 57. 14%. Survey included 23 questions no incentive was offered to any individual to complete and send.
Individual encounters ranged from 1 year to 15 years. All of the interviews were sound taped, create and then coded. Surveys data were stored in databases and later performed data mining with them. Along the way of data analysis grounded theories were used to derive constructs from collected organic data. Data were also transferred through data mining process to learn relations between different constructs.
Survey questionnaire protected questions from Development, Evaluating and Release Process. All individuals participate in team which includes adopted Scrum Framework. All jobs related to software development such as project managers, scrum masters, development team and quality confidence team are the individuals who responded to survey.
Questionnaire is fastened in Appendix I and their compiled email address details are attached in Appendix II.
CHAPTER 6
Identified Issues & Proposed Solutions
Identified Issues and Proposed Solutions
Several issues have been recognized from survey results and from interview time. These issues were directly affecting proper Scrum Implementation. These issues are related to management, development and release process and are the following.
Quality Items Pileup
Module Integration Issues
Quality of Code
Disruption in Team Work:
Mature vs. Immature Scrum:
Sprint Period:
Lack of Scrum Training:
Release Process
Backlog Management
No complex practices
Multiple teams
Metrics
Risk Management
Documentation
Too Idealistic
Quality Items Pileup: Due to agility of work in Scrum, clubs are bound to present something in a nutshell passage of time (either you scoped it properly or not). That is why they sometimes disregard quality of software and produce a pileup of quality related items. This is actually the biggest problem of Scrum framework or any Agile Methodology.
Without proper factor on those still left quality related items, teams can never make software quality better.
Module Integration Issues: Due to short time of interior release throughout a sprint, module integration testing cannot be performed properly all the days as it requires a lot of time for trials and quality assurance. This also creates some issues. Like when you open up a steering wheel of a car, you know that this wouldn't have an impact on the performance of your engine unit. But that doesn't hold true in case there is software. Any small update may have big impact on entire system.
Always give extra time to last inner release for tests and recognize that it's not a car, its software. For critical or large modules integration and quality confidence, a complete dedicated sprint is more preferable than doing in any other way.
Quality of Code: Due to agility of scrum, groups have short-term deadlines. If any designer is missing his deadline then he'll obviously put extra hours to cope up with it. This creates an issue of Quality of Code. One cannot always right correct and quality code at all times especially when he's working under pressure and putting extra time to complete the task.
Re-scoping for those responsibilities can solve this problem very easily. After proper re-scoping, responsibilities can be split into sub tasks. To show progress on job, some sub parts can be done in current sprint and remaining sections can easily proceed to next sprint. However those portions will be considered as lag and really should be done in next sprint.
Disruption in Team Work: When team goes from traditional SDLC towards Agility, like scrum, their professionals are not able to easily process independency of scrum, especially self corporation. From Study results, it has been noted that Product Owner and Scrum Professional interfere in team work by requesting statuses like they certainly asks in traditional SDLC.
Fig. 2: Disruption in Work during Sprint
This is against self organization and self applied inspiration which scrum talks. If team is not adult, then make team mature first and then start scrum. Proper training and scrutinize process can play important role in team maturity.
Mature vs. Immature Scrum: This has been also proved from results that Mature Scrum has relatively less issues than Immature Scrum. However the difference is very moderate. This is because Digital Prodigy Small (DPL) is wanting to check out scrum religiously. Fig. 3 is obviously displaying no. of issues facing both companies.
Fig. 3: Issues by Company
At this aspect, it is very important to say that Bentley Systems which has over 3 years of experience in Scrum doesn't have basic level issues, because their processes and Clubs are adult enough to aid Scrum.
Sprint Duration: Sprint length takes on an important role in efficiency of Scrum. Product Owner/Scrum Expert has to wisely select sprint period to get maximum benefits of Scrum.
Fig. 4: Issues by Sprint Duration
Fig. 4 evidently highlights the no. of issues having at different sprint length of time.
It is vital to create sprint length to the speed at which requirements change and the speed of which the team can deliver efficiency. Adding more work than the team cannot do makes difficult to make commitments and also to measure progress and velocity of team, and new "high-priority" work can disrupt flow.
Lack of Scrum Training: Results also exposed that 50% team members didn't received any formal training of scrum or they don't know completely how scrum process works. They got casual scrum knowledge either using their company other team fellows or of their scrum get good at.
Fig. 5: Insufficient Scrum Training
Teams having proper training of scrum process are much better than the clubs having no or casual training. They are simply better in home business and self empowerment. Through proper training of clubs, they can better understand how scrum process works and the particular team protection under the law are.
Release Process: Among the major issues is release process or the deployment process. Scrum presents agility in work and credited to agility; sprint deployment is the major concern for each team.
Teams have more deployments than before because their work is now divided into sprints. They have to be very careful for deployment. Release Management process can surely help in this case. Release Management also requires such guidelines which best suits to Scrum. Better regulations and their enforcement in team can deal with this issue very easily.
Backlog Management: Scrum provides inadequate guidance regarding the framework of the backlog. A couple of scrum management tools available in market but they are either too complicated or too simple which frequently doesn't meet team requirements. Complex tools in market are expensive. Groups who just designed scrum framework are not prepared to buy such expensive tool because Scrum is applied in experimental mode.
Problem to the solution is presented in Section-7.
No technical methods: Scrum shows good capability of project management, but there is absolutely no best complex practice available. Guidelines must be followed from other agile methods like Extreme Coding for good implementation of Scrum. Techie techniques like Test-Driven Development, Continuous Integration, Set Programming, Acceptance Tests and Refactoring should be added in Scrum Process.
Multiple teams: Through the survey it's been noticed that dealing with multiple teams is challenging as it is in traditional SDLC methods because scrum doesn't have strong advices onto it. Although scrum talks about "Scrum of Scrums" but this technique fails well when the groups are specially sent out. In fact agile itself is almost silent upon this issue. When employed in sent out environment, Scrum Experts require great deal of work and coordination among all the groups. This isn't a failing of scrum but a lack of strong process whenever using multiple teams.
Metrics: Scrum uses Burn Down graphs and Speed to measure metrics. These metrics aren't enough showing right picture unless the Scrum Master or Product Manager rests down and analyzes the melt away down chart for its peaks. These metrics are often ignored and not analyzed. Shed Down chart is good showing overall status of the status i. e. how much time have been spent or how much time have been still left. Although burn down chart shows amount of hours put in in a particular day however, not enough to provide in depth detail of this particular day.
As very good as velocity can be involved, it is defined as number of tasks/story details completed. You will discover cases when in one sprint velocity is high and on the very next sprint it is low. It is because it can't ever be used to identify low or high velocity in a task.
Risk Management: There is absolutely no plan or strategy in scrum to take care of risks. It's a significant factor for any project and therefore work is necessary in this field in Scrum.
Documentation: Agile is convinced in no records so Scrum also does indeed; however this phenomenon continues to be not successful in real environment where things come in and out through email or any other source which is quite difficult to keep track of.
Change should be tractable from Scrum Backlog. If any change comes, it ought to be relate with its related task.
Too Idealistic: Scrum assumes groups are of same self managing. According to rules of Scrum, Scrum get good at job is to eliminate all impediments for his team and vendor job is to supply the requirements in stories which will help to construct or complete the task incrementally. Yet, in practical this circumstance is not valid. It is not possible to make your team self prepared and self empowered all the time.
CHAPTER 7
Backlogs
In this section, Product Backlog and Sprint Backlog are presented.
Product Backlog
This is a template for Product Backlog management. Anyone can add requirements in this section. It offers backlog stuff like broad descriptions of most necessary specs, wish-list items, etc. prioritized by business value. It answers the "What" that'll be built. It really is open and only Product Owner can revise this backlog. It could also contain harsh quotes of both business value and development effort.
Fig. 6: Template - Product Backlog
In Shape No. 6, an example product backlog has been offered. Additionally it is known as submission supervisor where anyone can add requirements but it will only be approved by VENDOR. First column is Id which is the unique id of any item for product backlog. Its guide will be utilized in Sprint Backlog for tracking of any sprint item. Next column is Timestamp, which is the night out and time when the need was added in Product Backlog. Next to the Timestamp is Task which will be used for categorization of multi-projects. As a single team could work on several sub-projects hence it's important to add such categorization. From then on Owner column will notify about the person who possessed this necessity. Owner of that can be anyone but it'll be for stakeholders. This means item should be for stakeholders of the project. Next to owner is Type that will clearly notify about dynamics of the task. There may be more types of Type column but typically it'll be either "Change" or "Defect". Status column depicts about the position of the existing task. When job will be added first in Product Backlog, it'll be in Pending Status; later on it can be the pursuing statuses i. e. "Pending", "Under Progress", "Completed" and "Deployed". Severity column will notify about the main concern of that. It can be Urgent, High, Low and None. If an item is having Nothing severity then it'll be up to Product Owner when he chooses it for Sprint.
Sprint Backlog
This document provides the information regarding the put into practice the features for the forthcoming sprint by the team. Features are divided into small tasks for feasibility. These duties are normally believed between four and sixteen hours of work.
With each one of these details the whole team understands exactly what is usually to be done, and anyone can potentially take up an activity from the list. Responsibilities on the sprint backlog aren't assigned. They are in fact signed up for by the associates as desired, based on the set concern and the team member knowledge.
The sprint backlog is the house of the Team and the team packages the estimations.
Fig. 7: Template - Sprint Backlog
In number 7, Identification is the Sprint Backlog Identification and this must be unique for every single Sprint. Next to Identification is Request Administrator column. It will have Product Backlog Identification. Information and Details will contain information about job. It could be same Description of Product Backlog. Resources column will tell about resources working on almost everything. Any resource can pick task from Sprint Backlog but he/she must notify Scrum Master before starting work on it. Responsibilities may have anyone from these statuses "Under Improvement", "To Check" and "Done". "Under Improvement" means team member has started out focus on this item, "To Confirm" position will show that process has been completed from dev aspect and it's been forwarded to QC for confirmation. After verification from QC, process may have "Under Improvement" status; if QC founds any concern in it or it will has "Done" position if functional and non-functional requirements have been completed. All jobs will be destroyed into 5 parts i. e. Dev, Unit Testing, QC, Bug Mending and Deployment. During sprint planning every dev member will give Dev and Product Testing hours. QC gives their time of verification for an activity and Release Administrator (if there is any release process) will give his time for deployment. Insect fixing time will be accumulated once the task movements to "Done" status.
Columns which can be highlighted in red color are sprint times which fundamentally show sprint improvement for each source against each segment. Hours will gradually decline as source of information will work on the duty and then it will reach to zero which shows the task has been completed for a particular section. From this section Scrum Get better at or Product Director can critically analyze any learning resource or any activity. Data can be grouped by source and then can assess for bug hours and scoped time. Resource can also be analyze by Device Testing and Pests hours.
Burndown Chart
It is a graph that is viewed publicly showing the rest of the work in the sprint backlog. The burn up down chart is kept up to date on daily basis and gives a simple view of the sprint improvement. It also gives a quick account of reference. There's also other types of burn off down, for occasion the Release Burn down Graph which depicts the quantity of work left to accomplish the target determination for a Product Release (normally spanning through multiple iterations). the other you are Alternative Release Shed down Chart, which basically provides for the same, but plainly shows range changes release a Content, by resetting the baseline.
Fig. 8: Template - Burndown Chart
This burndown chart can easily be made from data of Sprint Backlog i. e. (Total Hours)/(Day Worked EVERY DAY)
CHAPTER 8
Conclusion
This research thesis identified that there are several factors which influences on Scrum Execution. A lot of the issues are related to management such as quality work pileup, release process, scrum maturity in company, formal training, management interference and sprint length of time are all straight related issues to management. These issues or problems are extracted from Study, Interviews and personal experience in Scrum Execution. Training on Scrum Construction can significantly effect on the implementation of Scrum.
CHAPTER 9
References
