Means Of Communications For Collocated And Distributed Teams While Implementing Scrum

The scrum development team
The scrum team is the heart of any scrum based project. The development team is directly responsible for manufacturing the functionality linked with the particular project. The development activity is carried out by the team members during the iteration or the sprinting activity, which generally lasts for up to two weeks. It is very important for the team members to “jell” with each other, and collaborate, because it is a prerequisite while implementing scrum. The physical location of the team members plays a very important part while the sprint is carried out. In most cases, the entire development activity, and the sprint too, is carried out in a single location, or the same place – under the same roof. However, with the advent of off-shoring and using scrum for complex and extended product development, it may become necessary for the team members to remain located in different geographical locations owing to various reasons.
 

Advantages of having a collocated team 

For healthy scrum implementation, high level, and frequent communications are essential between the team members as well as the scrum master while the project is underway. It is generally preferred that the team members are collocated. Collocation means all the team members share a common development location, and even similar infrastructure, during the sprint. 

There are several advantages of being collocated:

• Questions can get answered quickly and easily
• Problems can be fixed “on the spot” with minimal wastage of time
• Less friction is created in the interactions of the team members
• Trust is availed and rendered much quickly

Means of communications for collocated and distributed teams participating in the sprint
It is important to communicate in an effective manner to improve collaboration. Several types of tools and methods can be used to improve the collaboration amongst team members.
 

Collocated teams 

Teams working in and sharing the same office.

Since the team members are located in the same premises the preferred methods of communications can be:

• Face-to-face
• Messaging utilities
• Internal chat tools

 Discussions pertaining to the scrum process can also be facilitated using:

• Meeting rooms
• Scrum boards
• Wall displays
• Shared tables

Distributed teams
Teams placed in different geographic locations.

Some of the tools recommended for communication purposes are:

• Video conferencing tools and hardware/software
• Instant messaging utilities
• Chatting utilities
• Social media tools
• Shared screens
• Remote access facilities
• Specialized scrum software which emulate the functionality offered by traditional scrum boards

The daily scrum meetings cannot be conducted in a traditional matter since all the team members cannot remain present in the same place owing to geographical distances. In such cases, remotely located team members should participate in the meeting using electronic and online facilities. It is important to set up a fixed meeting time so everyone included in the sprint can participate easily.
 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

How Velocity And Story Points Relate To Each Other During Sprint Estimation

What is “velocity” in scrum?
Velocity is a simple, yet a powerful and effective method for measuring, or adjudging, the rate at which the development team carries out and delivers work during scrum implementation. Velocity provides a reliable estimate, which indicates what the team is capable of in terms of developing requirements and delivering them in a successful manner. The development carried out should be “shippable” and have a certain monitory value attached to the functionality to be considered as “successfully completed”. Only “completed” or “done” functionality should be considered while calculating the velocity.   
 

How are velocity and story points related?
Velocity can be a useful tool while estimating how much, and how quickly, the development team can complete work. Scrum involves a lot of planning, in addition to setting up goals and targets. Once the product owner creates the product backlog, a list which includes all the requirements needed to develop a product in totality, it needs to be determined how long the development will take, or alternately in how much time the project can get completed. It becomes necessary for the product owner to provide an estimate to the stakeholders and the investors regarding when they can expect the product to be developed, and made available for selling purposes. 

This is where the problem comes in. How can the product owner calculate how much time will it take? The obvious answer would be to calculate the development in terms of working hours and provide an estimate based upon the total number of hours required to complete the project. However, each team member possesses a different capability while delivering work. An experienced developer or programmer might take two hours for a single task, while an inexperienced or novice programmer may complete the same task in eight hours. In scrum, the entire team carries out development. A single story may be broken down into several tasks, and each task may be given to different developers – both experienced ones and novice. It further complicates things for the product owner. A possible way out is to associate a certain type of measure which can ascertain the difficulty level associated with a user story, and carry out the estimate using that particular measure which is independent of working hours. The “measure” used for calculating the estimate is called a “story point” in scrum.
 

What exactly are story points?
In scrum, story points are an arbitrary measure, and used to determine or indicate the magnitude or size of an object, which is relative to a similar object. Story points are generally used to measure the user stories or product backlog items. Story points are used to estimate the development effort required for developing the features and requirements. For example, when a particular task may be associated with a story point, an experienced developer might find the task easy and associate five story points to the particular task. On the other hand, a novice programmer might find it very difficult and associate ten story points to the same task. This would create a discrepancy, since the task remains the same, yet its level of difficulty changes from person to person. In such a case, the scrum master considers the mean value, and allocates story points to the task. 

In the above case, the mean value would be ten points for the novice programmer plus five points for the experienced one divided by two (the number of developers associated with the task) which equals seven point five.
Level of difficulty                Story points    Mean value   
Experienced programmer    5                      (5 + 10) / 2
Novice programmer            10                     7.5
 

Story points and velocity estimation
Once the product backlog is ready, the product owner starts assigning story points to the user stories in the backlog. During the scrum process, he or she may also take the help of scrum master while determining and allotting the story points. Suppose the product backlog is assigned a value of three hundred story points - for the entire project to be developed. Now, the product owner calculates how much work the developers can take up on the basis of story points. An experienced programmer might be able to take up more work i.e. contribute more story points towards the development. Suppose he or she might be able to contribute fifteen points of work during the sprint. The novice programmer might contribute five points, while an intermediate programmer might be able to contribute ten points. Therefore, the total story points covered by the developers during the sprint can be summarized as:    
Experienced programmer            15 points
Novice programmer                     5 points
Intermediate programmer            10 points
Story points covered by the
programmers during the sprint     30 points
 

Therefore, work equivalent to thirty story points can be expected during one sprint. Since the project is worth three hundred story points, the total time taken is equal to:
Total story points associated with the project            300 product backlog points
Points covered during one sprint (On an average)     30 sprint points
Therefore, total number of sprints required               300 / 30 = 10 sprints
One sprint                                                                   2 weeks
10 sprints                                                                    2 x 10 = 20 weeks
 

As per the above calculations, it would take twenty weeks or five months, if we are to consider four weeks to a month, to complete the project. The estimation would be five months.
 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

Are You Ready For Scrum? Do You Know About Scrum Implementation And Issues Faced?

Why “C” level management prefers scrum framework
Scrum offers many advantages over traditional Waterfall methods. The development process is much quicker and more dynamic. There is more client interaction. It is much easier to control production processes and cut down upon non-productive or non-performing tasks and activities. The ROI can be drastically increased. The list of advantages may appear to be endless. These facts are known to many decision making and key management personnel across the world. Moreover, there is a general belief amongst many management level experts that if you employ scrum, you will benefit from a healthy business environment which is more receptive and open to changes, the productivity levels are substantially increased owing to improved collaboration between team members, management, and stakeholders, and perhaps the most important aspect why scrum is so popular – how can a business grow substantially without having to invest huge amounts of capital in infrastructure and human resources? 

Capital is always a constraint and a valuable form of resource for almost all businesses, and managements always seek ways and means to increase the productivity and profit levels while keeping the overheads low, and in control. It is a known and accepted fact. Scrum might just help you to do this, and much more, if you know and understand scrum, and implement it properly within your production process. This is why people have many expectations from scrum frameworks.
 

Reality about scrum implementation
What most experts fail to understand is there is always a string attached if you plan to make money without putting in all due efforts. In many ways, saving money is synonymous to earning it, and scrum helps you to save upon the working and production costs which can result into money saving and profits. First of all, it is not that easy to implement scrum. You need to be educated about scrum framework, and possess the required experience and skill levels to implement it successfully. In addition, transition from traditional methods to scrum is involved with its own particular issues. The business processes have to accommodate and adjust to scrum working. Certain departments have to change their basic method of working to support scrum implementation. Here are some of the issues you might face while incorporating the scrum process into your business.   
 

Acceptance by chief level officers
"C" level executives are more tuned to working with organizations following traditional Waterfall methods. They are used to, and can easily delegate their authority within traditional working models. They are responsible for delivering reliable and consistent outputs to the stakeholders, and to do this they have to set up, or build a certain "velocity" or pace at which business processes are required to function. The basic idea is to create optimum working conditions in which maximum productivity can be achieved out of the business processes.
 

Issue:
Scrum is all about collaboration and distribution of authority. The team works as a composite unit and delivers productivity. Even though the product owner holds many trumps, he or she can be challenged by the team members, and at times if necessary by the scrum master, regarding the productivity of the development process. Team members also have the right to question or even reject the user stories if they find it difficult to adhere to its development principles, or if development is not feasible.
 

The absolute authority of "C" level executives is often challenged by the team members, and they might be even forced to answer a few technical questions, which might not go very well with their egos or self esteem. If scrum is to be effectively implemented, they have to come to terms with the new method of working, and make some amendments in their thought processes and working patterns.
 

Human resources working and evaluation activitiesIndividuals opting for scrum need to be specially trained in the framework before they can effectively contribute towards the development activity. The HR is responsible for choosing the right candidate for a particular profile, and in case of traditional development methods, the candidate does not need any special training. Generally, qualifications and experience suffice while appointing a person for a particular position.
 

Issue:
With scrum, everything changes for the HR department. They are forced to create new career paths and roles for scrum-trained employees. Moreover, it may prove to be difficult for them to work out several increment and incentives related issues for the team members. How can employee efforts be monitored or calculated? Since scrum is all about teamwork, how do you determine the productivity of individual team members? Do you consider the overall productivity of the team? If so, which member has contributed more towards the development?
 

It is not easy to be objective while considering the overall picture. HR may have to work out special monitoring processes to determine how much a particular team member is worth to the organization, and how much he or she is contributing towards the business's growth.
 

Finance and budget considerationsIt is much easy to determine the budget requirements and calculate the overhead costs in case of Waterfall models. The management is able to correctly identify and adjudge how many resources are required to carry out the production activity. It is also easy to allot budget for a particular business process. However, in case of scrum, development is possible only through teams, and the budget is to be directly allotted for the team's functioning. It may be difficult to find out the true worth of a team in terms of productivity and its contribution towards business growth and profit margins earned by the business.
 

Issue:
The management may feel uncomfortable and even insecure while allotting budget directly to the team. The management needs justification while allotting budgets, and the team may not be able to justify the expenditure each time it seeks financial resources. Moreover, the team is responsible as a whole, and the management may not be satisfied with the justifications provided by the team members. There is no "single" person who can be held responsible if development starts going haywire.
 

The management requires to thoroughly understand how scrum works, and also recognize the fact that even though scrum offers many benefits, one needs to adapt to its implementation - and this can be difficult in the initial stages. The basic problem is adjusting to a different mindset, which caters more to dynamic changing environments rather than traditional seemingly safe and secure, yet fallible working models. 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!