Share on facebook
Share on twitter
Share on whatsapp
Share on linkedin

Scrum

Scrum Model

Background

The word Scrum from rugby game where players are united in a specific position to achieve the common goal. (Ionel, 2008). The first software was developed using Scrum model in 1993 at Easel Corporation. Jeff Sutherland was the Chief Engineer who defined Scrum roles and built first portfolio of product. Dr. Jeff Sutherland developed first product and sprint backlog and hired Product owner and Scrum master for the Scrum project first time.

In 1995, Jeff Sutherland gave idea of Scrum team to Ken Schwaber who was CEO of Advanced Development Methods. They both worked together for further development in Scrum. Jeff Sutherland educated the Yahoo engineers about Scrum in November, 2005. One evening, Yahoo president Pete Deemer called a meeting of senior management and decided to roll out Scrum companywide (Sutherland and schwaber, 2007 ).

Many large and small companies are using Scrum for the software development like Yahoo!, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE, Capital One and the US Federal Reserve. Scrum is an iterative model used for software development.

Introduction

The SCRUM methodology is suitable for all types of project, product and application development. (Ionel, 2008). Scrum divide problem into tasks and assign each task to group. Duration of each sprint is about four to six weeks. The time of sprints is fixed and it ends on a specific date whether the work has been completed or not, and are never extended. (Deemer, 2010).

At the end of each sprint, team demonstrates the progress of project to the product owner, stakeholder and customer. Project’s progress is transparent to customer even he can change the project execution plan in the middle of the project which is not possible with traditional approach. Scrum prefers multitask worker instead of team members working with single job title so that team members could do any task where the work overload is more. In this way team help and learn new skills from each other.

 Role of Scrum

There are three main roles in scrum.

  1. Product Owner

Product owner is responsible of collecting all inputs require to build project from customer or end user, stakeholders.  He prepared features list and prioritized them according to user demand means what should be at the top of list for sprint. He managed Product Backlog and ensures that it is visible to all. Product Owner can add or remove features from product backlog. He also confirms, what is going on in the next sprint (Sutherland and Schwaber, 2007).

Product owner is responsible for profit and loss of product. Product owner reviews the business impact for product backlog items. He is different from traditional product manager because he personally interact with team members and actively involved in the development.

He offers priorities and encourages team members. Product owner gave them free hand to do work and use their capabilities without any pressure. He decides the release date and reviews results after each iteration. He estimates the cost of developing features with the help of team members.

2. Development Team

Scrum team follows the instructions of product owner. Team in Scrum is cross-functional and it uses all the capabilities and expertise needed to deliver optimum result of sprint. Scrum gave free hand to team members within the boundaries of project to do anything to reach the goal of sprint. Scrum team is self-organize with high degree of autonomy and accountability. Team has authority of breaking down the product backlog into tasks and sub-tasks.

Scrum team is responsible for analyses, design, develop, test, technical communication, document, etc. Team developed the product according to the features provided by product owner and gave ideas to product to achieve best result. In addition, Coordination among team members should be high and dedication to work should be optimum. Scrum team attend meeting for sprint planning. Usually number of team members in Scrum is seven plus or minus two people. Team creates sprint backlog and update backlog item status daily. Scrum team helps the Product owner to estimate the cost of developing features.

3. Scrum Master

Scrum master use all his resources to help and guide the development team and product owner to achieve sprint goal. He protects team from outside interference and threats so Scrum master should be very energetic, dedicated and sincere with his job.  He ensures that all team members understood the sprint goal and deadline. Scrum master should be expert in analysis, Design, Testing, Product Management, Project Management, or Quality Management.

Scrum master may resist any changing introduced by product owner in the middle of sprint. Instead of assigning tasks to team, Scrum master facilitate and cooperate with the team to complete process. He removes any impediment to achieve goal..

Responsibilities of Scrum Master

Followings are main responsibilities of Scrum master.

  1. Update burn down chart on the base of tasks completed, new started task or any new added, an estimate change. Burn down chart shows the remaining work day by day.
  2. He keenly observes the task in progress, either it will complete on time or not.
  3. Scrum master helps to remove impediments or blocks of any task. He try to solve it within team or across team and involved management if company block the team to achieve goal. Some impediments need management attention to resolve.
  4. Personal issues among team members are very crucial and need to resolve on urgent bases. During work at ATT Bell Labs,  Jim Coplien did case studies over 200 projects and noted that over 50% productivity loss were due to personal issues (Sutherland and schawber, 2007). So its duty of Scrum master to resolve all personal issues by dialogue within team or scrum master may take help of management or human resource group to resolve issues.
  5. Scrum master ensures that team members are functional and productive.
  6. He ensures that team members are working according to feature list and make sure the team cooperation and coordination with each other.
  7. Scrum master is responsible for issuing daily Scrum meeting invitations, sprint review and planning of meeting. He advise product owner about addition or removal.

 Ceremonies of Scrum

      There are main three ceremonies of Scrum.

1. Sprint Planning Meeting

Sprint meeting is require before start of any sprint because success of sprint depends upon sprint planning meeting execution. It is mandatory for Product owner, scrum master and all team members that they attend sprint planning meeting. This meeting can continue maximum eight hours. Basically, there are two parts of sprint meeting. In part1, product owner and team members review items or feature list of product backlog and choose high priority items for implementation in sprint on the base of team size, available hours and level of team productivity. Top priority item kept on the top. It is also discussed “what goal they will achieve after completion of selected items list?” Actually in parts1, main focus is “what product owner wants?” Meanings of “Definition Done” is explained.

      In part2 of sprint planning meeting, main focus is explanation about selected tasks for implementation. Scrum master guide the team members to breakdown the product features into sprint backlog. It is discussed “How to implement the tasks?”How much time and cost is required to complete selected task for sprint? How much working hours each member have for sprint related work excluding lunch break, attend meeting, doing email time etc.? Usually team members are 4-6 hours available for sprint related work. An estimated chart of available working hours of each member is prepared as shown in figure .

Fig. Sprint Planning Meeting

2. Daily Scrum Meeting

Arrange daily scrum meeting on each work day for 15 minutes or less. Main purpose of this meeting is to synchronize the team work and gave report of impediments faced by any team members. Each member tell about status of work assigned him/her. Everyone can attend daily scrum meeting but only development team members have to give answers of three questions.

What I have done yesterday?

What I am going to do today?

Which impediments I can face?

This is detail discussion meeting. If there is need of discussion then call urgent follow up meeting daily scrum meeting. Implicitly team members gain knowledge during meeting and team continuously assess its own progress achieve target of sprint.

3. Sprint Review

Arrange Sprint review meeting at the end of sprint. Team gave demo about product built during sprint. In sprint review meeting, product owner inspect and adapt product built. It is just 30 minutes demo about built product no power point slide show. Basically sprint review meeting is deep conversation between product owner and team members for further advice. Scrum master make sure that everyone know the “Definition Done” and prevents of demonstrating the items that are pending  yet. Not done items go back to the product backlog and can be developed in the next sprint according to the priority given by product owner. In this way software quality is visible to product owner, team members, and scrum master,  plus customers, stakeholders, experts, executives or anyone who attend this meeting.

Artifacts of Scrum

There are three main artifacts of Scrum

1. Product Backlog

First of all product owner collects all requirements of project going to develop. Customer involvement is crucial in Scrum. Once requirements and user stories are clear then product owner makes feature list priority wise. Prepare the product backlog and put high priority item on the top. The selection of high priority items is based on the customer demand and business value. The product backlog remains until the completion of project and product owner have to update it  regularly according to the customer demand, market value or new ideas need to add. Only single product backlog exist for whole project. Product backlog item are different in size. Large size item is break down during sprint planning meeting. The main advantage of product backlog is that we save our time of writing detail requirement specification. write only those requirements in detail which product owner and team decides.

productFigure Product Backlog

 

2. Sprint Backlog

When the product owner and team understood the overall design of project then set top priority items list in product backlog. After that scrum master leads the team to decompose the product backlog items into sprint task list that form a sprint backlog. The sprint backlog includes all those item which team has to build during sprint. In sprint planning session, assign tasks to team member and set time estimation. Once sprint has started, team members cannot change the tasks until there is  require extreme case of changes. In such case continuing of sprint is useless effort of team members and wastage of time. Product owner can stop sprint in extreme case with full support of team members. Update Sprint backlog daily usually during daily scrum meeting. Spreadsheet shows the sprint backlog as shown in figure.scrum

Figure: Sprint Backlog

 

3.Burndown chart

Burndown chart is basically a graph which Scrum master or team update daily. It shows the remaining work or effort required to complete the sprint tasks. Actually this is downward sloping graph which reach to the zero effort remaining by the end of sprint that’s why its name is burndown chart. Burn down chart is usually used in Scrum to show the remaining work in the sprint backlog which is update daily and shows progress of sprint.

Burn down chart helps management to solve problems such as scope creep or a deviation from the planned project at an early stage. Although burn down chart is simple and easy to understand but there are some limitations such as it cannot represent the accurate reflection of the project team output when added or removed requirements in the mid project (Akif and Majeed, 2012). Since burndown chart is made on spreadsheet but some team members look more comfortable to make on white board or wall with pen.

burndownFigure: Burndown chart

agile

Agile Methodologies

Agile methodologies is an iterative approach that builds software incrementally instead of delivering complete project at once (Shelly, 2015). It divides the project into small iterations and continuously delivers different tasks after completion according to priority of user. Iteration length in agile methodologies varies between one to four weeks. According to researchers shorter iterations have lower complexity and risk, better feedback, and higher productivity and success rates (Larman, 2003). Agile methodologies are best to reduce the cost of software development.

Actually agile development is an umbrella activity that illustrates different agile methodologies like Scrum, XP, Crystal, FDD and DSDM as shown in figure 1. Agile works over comprehensive documentation, customer collaboration during software development. It response quickly to changes, individual and interaction over process and tools (William, 2010).

agile1

Figure 1 Agile development is umbrella activity

In the recent years, agile development methods gained popularity as an iterative, incremental and quick response to changes using short development cycles. Agile methodologies reduce the problems of traditional software development methods and adapt changes with the help of incremental and iterative process.  Although, we studied many agile methodologies in literature which focus on different aspects of projects. The success of project depends upon the selection of best suitable method for software development.

1. Crystal

Alistair Cockburn in 1998 made Crystal  which is a lightweight family of methodologies. The main focus of crystal methodology is strong communication and interaction among people of project team. Larger project requires complex methodology and more man power with better coordination (Williams, 2010). Different crystal methodologies like Clear, Yellow, Orange, Red, Maroon, Blue and violet are introduced in the literature. Although Crystal methodologies are classified according the project size but each member of crystal family is assigned color according the complexity of methodology: the dark color is assigned for heavier project.

 2.   Extreme Programming

Extreme programming was introduced by Kent Beck on the base of some fundamental principles that is communication, simplicity, feedback, courage and respect. In XP, executable code and automated test drivers are produced instead of detail of requirements and design documentation. XP is a light weight methodology and design for small team. There are twelve core practices in XP as shown in figure which describe the activities cycle. Tight cycle of the programmers is shown in inner loop while outer loop describe the planning cycle between programmers and customer. Communication and coordination among team is shown in Figure 2  middle loop.

XP

Figure 2 XP Practice

User requirements are gathered and these requirements are arranged according to priority. Project is completed in different iterations and coding of these iterations is developed with the help of pair programming. Pair programming required 15% more effort than solo programming (Maurer and Martel, 2002). Cost will increase with the increase of man power as shown in figure3.  XP does not support code ownership because every developer has code understanding and can modify it. there is no special meeting for code review meeting in because XP rely on code review while working in pairs (Khramtchenko, 2004). In addition, XP team use common name and description (metaphor) for development and guidance. Iteration plan could be adjusted on the base of new requirements. In next phase, developed iteration is checked for bugs.

extremes programming

Figure 3 Cost increase with man power

 

3.  FDD (Feature-Driven Development)

Jeff De Luca and Peter Coda made FDD (Feature-Driven development) and got recognizable name in 1997. Feature-Driven development focus on upfront design and building phase rather than focus on development cycle (Shelly, 2015). FDD rely on two main stages. First one is preparing a feature list to implement and second is feature by feature implementation (Khramtchenko, 2004). In first step, developer gathers all the stakeholders’ assumptions and requirement and  built detail model. This step is very critical and require full time customer participation.

In second step, development team is divided and particular feature list is assigned them to implement. it requires only one to two weeks for implementation.  Each team has head that is responsible for code segment that implement particular feature. FDD strongly support code ownership. Every developer knows about its owned code. FDD suffers if any developer leaves the team but it could be covered in some extent by reviewing design and sufficient code documentation. In addition, code review meeting also helps developers to view code of other developers. There are different development processes in Feature –Driven Development as shown in Figure 4.

FDD

Figure 4. FDD (Feature-Driven Development) process

Feature Driven-Development processes are described here one by one.

 a.  Develop an Overall Model

At this stage, describe High level descriptions. This stage prepares Use cases and functional     specification.  All team members and chief architect discuss High level descriptions and agreed upon object model for each domain area.

b.  Build Feature a List 

Built list of comprehensive feature to develop a system according  base of object model and functional specification. In feature list all function that is mandatory for the client point of view is added. After that, finalize the feature list  after viewing of user and validity of system’s sponsors.

c.  Plan by Feature

Prepare sequence of  feature list according to priority and assigned to chief programmer to develop functions (Palmer and Fleshing, 2002). After that, made overall schedule of feature list. Assign classes to developer (class owner) which are already defined in the “developing an overall model “

d.  Design by Feature and Build by Feature

These are iterative procedure and iteration completes from one to weeks. Multiple teams designing and building their own feature list simultaneously. Domain expert guide to complete task such as design, coding, unit testing, integration, code and design inspection (Williams, 2007). When iteration is completed successfully then completed feature is added into main build and new features are added from feature list in “design and build feature process” to develop.

4.  Dynamic Systems Development Method (DSDM)

Dynamic Systems Development Method (DSDM ) is an incremental agile method and in 1990’s it was most popular among software developers. Incremental prototype is used to control the tight time constraint to develop software. In order to work, phases, sub-phases, roles and principles defined. There is no phase for security element so DSDM is unable to develop secure software (sani et al., 2013).

The DSDM framework is suitable for agile and traditional development processes (Benjamin, 2004). Usually, DSDM projects work with one or two teams: the second team tests the product developed by other but researchers suggest that in a single team about 5 to 6 people are ideal (Benjamin, 2004). There are main four phases in DSDM that is feasibility, functional model iteration, design, build iteration and implementation with several sub phases.

Initially, do  feasibility study to define problem and cost estimation. Feasibility report and plan outline for development is made. In last three phases actual development is done where analysis, coding and testing is done. On the base of prototype we make decision whether to move in the next phase or not (shelly, 2015).

5. Adaptive Software Development (ASD)

Adaptive Software Development (ASD) was developed by James A. Highsmith. In ASD repeating series of speculate, collaborate and learn is used by replacing the traditional water fall cycle.  This method worked with iterative and incremental method with constant prototyping. ASD does not impose the use co-located team but focus on inter-team collaboration.

There are three main process cycle of Adaptive Software Development as shown in Figure 5 which  provides continuous learning and adaptation.Adaptive

Figure 5 Adaptive Software Development Life Cycle Model

a.  Speculation

This is basically a planning stage for the software development. At this stage, identify  requirements so that project objectives and time box could be set. First decide  length of iteration then assign box is to the each iteration. Each Team member writes Objective statement and assign features to iteration (shelly, 2015).

b. Collaboration

At this stage of collaboration team must support and trust on each other. In addition, Team members must communicate with each other to collect information and to solve complex problem. Team members cannot make critical decision individually so there is need of team collaboration to reach the common goal.

c.  Learning

At this stage, the development team takes a technical review and provides feedback. Team learns partially developed code and point out the problems to reduce the cost and amount of rework. After the completion of iteration the team should learn about;

  • Team member’s collects customer feedback after explore the application and note down the changes specified by the customer.
  • Review performance of team then made decision for further improvement in performance.
  • Review the project status, and plan for next iteration.

6. Scrum

Scrum is an iterative and incremental AGILE methodology. The SCRUM methodology is suitable for all types of project, product and application development. (Ionel, 2008). In Scrum problem is divided into tasks and assign task to group. It is also called lightweight process which means minimize the overhead of process and maximize available time for useful work. In addition, it makes progress in sprints and duration of each sprint is about four to six weeks. The time of sprints is fixed and it ends on a specific date whether the work has been completed or not, and are never extended. (Deemer, 2010).

At the end of each sprint, team demonstrates the progress of project to the product owner, stakeholder and customer. Project’s progress is transparent to customer even he can change the project execution plan in the middle of the project which is not possible with traditional approach. Scrum prefers multitask worker instead of team members working with single job title so that team members could do any task where the work overload is more. Hence team help and learn new skills from each other.