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 Scrum Can Help To Reduce Risks In Projects – Risk Mitigation In Scrum

Every project in scrum, irrespective of its size and scale, is subjected to certain risks. The risks may be minor in nature, in which case they could be easily solved. Alternatively, they could be of larger magnitude, and would really tax the experience levels of the scrum master as well as the product owner to resolve them. Catering to risks is one of the main reasons why managements and “C” level executives opt for scrum methodology. Actually most people interpret risks in a negative way. It is interesting to know that risks can be negative as well as positive in nature, depending upon the outcome they result in. Risks, which result in a positive manner, are termed as “opportunities” while those that negatively affect the project are known as “threats”. In a simple language, a risk can be understood as a particular situation, unknown about what kind of result it will deliver when it is conceived, and which can result into an advantageous situation, or it could adversely affect the project working as well as the result the particular project is fundamentally supposed to deliver. Risk management is an inherent part of scrum methodology.
 

Minimizing risks (threats) using scrum methodology
While positive risks, or opportunities, are inadvertently welcomed, it is the risks, which create a negative effect in the ongoing project, or threats, which are of concern to scrum enforcers. Scrum helps to minimize risks in several ways:
 

1. Flexibility exhibited by scrum reduces business-environment-related risks 

Unlike traditional development methodologies, scrum is highly flexible, and possesses the capability to add or modify the project related requirements at any time during the project life cycle. It helps the management to respond in a positive manner to threats as and when they arise. The management can easily cater to unforeseen circumstances when they arise. It is very easy to remove the user stories from the product backlog and replace them with new ones. The product owner can add new stories whenever required as per the wishes of the stakeholders. Moreover, if a particular set of requirements becomes obsolete or useless in terms of its functionality, it can be removed from the product backlog, and its development can be curtailed. This is not possible in a Waterfall method.
 

2. Constant and regular feedback reduce expectations-related risks
The entire project development is carried out in sprints. Each sprint is preceded by a daily scrum meeting. Scrum provides plenty of opportunities to avail feedback regarding exactly how much development has been successfully completed until date, and how much of it is still pending. The scrum board reflects the changes as and when they occur in real time, so the management is always kept informed about which user stories are currently being processed for development. Stakeholders can verify the work delivered at the end of the sprint, and if they are not satisfied, they hold the right to reject it. The investors are never caught off guard owing to miscommunication. They can always check up the development status and act accordingly.
 

3. Team ownership helps to reduce estimation related risks
The team creates proper and effective estimates making use of prior development related experience. Sprint retrospectives help to identify potential pitfalls likely to occur again in the future while sprint planning helps to include proper user stories for time bound and acceptable development. Team ownership helps to reduce estimation related risks. 
 

4. Increased transparency reduces non-detection risks
Scrum advocates transparency. Everything and each activity carried out by the scrum team is made public as soon as possible. As a result, any risk, if it arises, is detected early by the concerned person, and the person is supposed to take up further course of action to remove the risk. Risks are detected and communicated early, and this leads to better risk handling as well as risk mitigation.
 

5. Iterative development reduces investment-related risks  
The delivery value is continuously presented when scrum is implemented. The basic advantage of scrum is that functionality is delivered in stages after the sprint is completed, which generally takes from 2 weeks to 1 month depending upon how long the sprint lasts. This is not possible in case of waterfall methods since the results are derived in the final stage of the product development cycle. It then becomes too late to respond to the development, and to introduce new changes because the entire project is completed by that time. Scrum helps to reduce investment related risks.
 

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!

Importance Of A Sprint Planning Meeting In Scrum Framework

Significance of the sprint planning meeting
Whenever scrum is to be implemented for a project, user stories are carefully worked out, and a product backlog is painstakingly prepared in which user stories are properly categorized, and set up in order of their importance. The product backlog is prepared by the product owner, who is also responsible for ensuring that the user stories are properly taken up by the team members. The team carries out the actual development work during the sprinting activity. The sprint forms the backbone of all developmental activities associated with the particular project, and therefore it is required to be properly planned in order to get the most out of what scrum has to offer. For this, a special meeting is held before the sprint is to be executed. This meeting is known as the sprint planning meeting.
 

Who attends the sprint planning meeting?Since sprint planning involves the formation of the sprint backlog (The list of user stories to be developed by the team members during the sprint. The product owner decides which stories are important, and recommends them to the team members who prepare a list of items which each team member is supposed to process and develop. This particular list is known as the “sprint backlog”). So the product owner has to remain present during the meeting. As the development is to be carried out by the team members, they too have to attend the sprint planning meeting. In addition, the scrum master is responsible to ensure that scrum is properly enforced, therefore it is also mandatory for him or her to remain present during the meeting.
 

The sprint planning meeting is attended by:

• The product owner
• Scrum master
• Team members

What is the sprint planning meeting like?
The main purpose of the meeting is to create the sprint backlog with respect to its user stories and development tasks. The product owner has to decide which user stories are most important and which of them should be ideally incorporated into the sprint backlog. Once the sprint backlog is decided by the product owner, the team members have to decide how the sprint backlog should be processed for development purposes. So, mainly two aspects – the “what” aspect and the “how” aspect pertaining to the sprint are to be discussed and worked out during the sprint planning meeting. The meeting is generally divided into two parts – the first part catering to the “what” aspect, and the second part which deals with the “how” aspect.
 

The two parts are further explained as follows:
 

1. Objective definition – the “what” aspect 
In the first section or the initial part of the meeting, the product owner briefs about the user stories which are of highest priority and instructs the team regarding the acceptance criteria associated with the user stories, and what kind of functionality are demanded by the stakeholders. The product owner does most of the talking and answers questions as well as queries put forward by the team members. The scrum master is a passive participant, but can also ask specific questions if he or she is not clear about a certain aspect regarding the implementation of scrum during the sprint.
 

2. Task estimation – the “how” aspect
During the second phase of the meeting, the “how” aspect is taken up by the team members. They segregate the user stories into individual tasks, and each member takes up a list of tasks to develop during the sprint. The tasks are unanimously selected depending upon the levels of expertise possessed by each team member. The main objective of the second phase of the sprint planning meeting is to ensure each team member has enough tasks on hand to last the entire sprint duration. For effective scrum project management too many tasks should not be taken up so that the sprint cannot be successfully completed. Scrum makes it mandatory for each given task to be completed by each team member at the end of the sprint duration. At the same time, enough tasks should be taken up so that the team member does not run out of development work during the sprint. 
 

Scrum emphasizes upon active participation and involvement of every team member. It is highly recommended that the scrum team should undertake a proactive approach regarding one’s involvement and responsibilities during the implementation of scrum. The sprint planning meeting should ideally be conducted keeping these principles in mind.  
 

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

Features Of An Ideal And Effective Product Backlog In Scrum Methodology

What is a product backlog in scrum?
In scrum methodology, a product backlog consists of an ordered list, which includes everything needed to develop a complete product, right from its inception. The list items in the backlog typically include the features, functionality, user requirements, etc. associated with the product to be developed.   In certain cases, the backlog may include additional features or functionality, which may be needed to complete an unfinished product or to develop and advanced version of an existing product. At its very core, a product backlog generally includes a list of product related requirements, of all kinds, and is managed by an individual who has a proper understanding of what needs to be developed and in what manner, as well as the ability to comprehend all client’s requirements.    
 

What are the ideal characteristics of a product backlog?
An ideal product backlog should have certain characteristics which can help it to become effective and easily implementable.
 

Clearly visible to every person
Agile and scrum principles stress a lot upon transparency and collaboration. For effective scrum product management, the backlog should be easily accessible, and made available to each scrum member associated with the project. Each member should be able to apprise himself or herself about what is going on, and what is being planned. The basic objective of making the product backlog visible to everyone is to avoid undue surprises and to prevent disruptive behavior amongst team members. 
 

Should be unique, ordered, and centralized
To avoid confusion or misunderstandings regarding the project development, it is very important for the product backlog to be unique and located in a central place which is accessible to everyone. Maintaining several versions and updates of the product backlog can often lead to confusion amongst the team members and the product owner as to which version should be followed or implemented. Having a single version helps to remove this confusion from occurring. The list should also be ordered as per the priorities set up by the product owner. It is important to develop those user stories first which are more important and carry more value. The backlog should be centrally located so that each member can easily access it independently, without having to depend upon a particular person who can make it accessible to others. It is important to do this to avoid information hiding and power games from being initiated. Scrum lays stress upon information sharing and preventing any single person from assuming total authority.
 

Dynamic and real-time update support
A product backlog is a “live” element within scrum methodology, and should possess the ability to reflect the most recent changes and updates occurring in the development of user stories during the Scrum sprint process. The main objective of scrum is to increase the involvement of client and team members, so that the development can be carried out in a dynamic manner, with everyone involved knowing about the most recent project status i.e. what development has taken place till date, how much of the product backlog is still pending, and which team member is involved with a particular development task. Ideally, the product backlog should display the most recent status, and have the capability to quickly incorporate the changes taking place in live environment.  
 

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

3 Serious Pitfalls Which Every Scrum Master Should Avoid – Implement Scrum Successfully

The scrum master holds a very high position and an important one too, while executing projects using scrum methodology. The main role of the scrum master is to ensure that the development team effectively employs scrum during the sprint activity. If scrum is properly implemented, each member of the team remains busy with the tasks allotted, or taken up, by him or her. It is not required for the member to seek guidance from the scrum master as to what should be done next, or what task need to be carried out. The main objective of the sprint planning meeting held before the commencement of the sprint is to ensure that proper and enough tasks are taken up by each team member. 

However, at times due to various reasons, which ought to be avoided at all costs, the scrum master knowingly or unknowingly transgresses his or her responsibilities, and extends the primary role of the scrum master. This can lead to undesirable results and ineffectual implementation of scrum methodology. It can also lead to increased development costs and bloated overheads – something every business owner tries to avoid at all costs. So how does a scrum master know that he or she is making a mistake? How does the person find out whether he or she is transgressing the responsibilities associated with being a scrum master?    
 

The three main mistakes of a scrum master
It is not an easy task to become a scrum master. If the person is new at the job, or lacks enough knowledge or experience as a scrum master, it can be very easy to fall back upon doing what project managers know best – behave and function as traditional managers. It can be very easy to fall into this trap, and many scrum masters often fail to avoid this pitfall during the early stages of their career. A scrum master is not supposed to behave as a typical project manager. Scrum methodology does not support or subscribe to it. 

Certain indications can help you identify and avoid the pitfalls:   
 

1. Start assigning tasks to team members
During the sprint process, if scrum is implemented properly, each team member has enough tasks on hand to last the entire sprint duration. The very purpose of holding a sprint planning meeting before starting with the sprint is to ensure that proper and enough tasks are taken up by each team member, and each task is allotted a predetermined time during which it is to be completed. So when scrum methodology is enforced in a proper manner, team members generally do not run out of tasks, and are not required to ask for new tasks when the sprint is currently underway.
 

Pitfall
As a scrum master, if any team member runs out of tasks and approaches you for new tasks before the current sprint is over, you might be inclined to allocate new tasks to the person. This is a pitfall, and should be avoided. It means that the sprint planning meeting was not done in the correct manner.
 

Solution
Care should be taken to select proper user stories into the sprint backlog, from the product backlog, and each team member told to take up enough tasks to last the entire sprint. The time allotted to the development of the task should be properly decided and set up in a manner such that excessive time is not linked with a particular task. The exact amount of time should be allotted to the tasks, and the tasks should be added up so that they span the entire sprint duration.
 

2. Taking decisions for the development team
It is highly common for team members to discuss about work and problems occurring during the sprint activity. Very often, the members depend upon each other’s help and guidance to solve problems occurring during the development process. It can be very tempting for the scrum master to “volunteer suggestions” which can solve the problem, or provide a solution which can eliminate the issue.
 

Pitfall
The scrum master actively involves in the discussion by prompting the team members to explain the problem, and subsequently offers an alternative which solves the issue on hand. Team members accept the verdict and start implementing the solution within their development activity owing to a higher degree of problem solving experience held by the individual. This is also a pitfall, and ought to be avoided.
 

Solution
The scrum master is a passive participant as far as sprinting is concerned. He or she is supposed to observe the team members and ascertain whether they are following scrum methodology, and instruct them to follow proper techniques in the event they are making a mistake. Care should be taken to select proper team members who are experienced and well conversant with the development process. Typically, the team should consist of members who are thorough professionals and capable to providing correct results in a time bound manner. The team should be selected well in advance before the sprint commences and the product backlog is created. The product owner and the scrum master should carefully pick the team members once the product backlog is created. The user stories can give an idea about the complexity of the development to be carried out, and what levels or expertise are ideally required.
 

3. Function as an intermediary or a “go between” between the product owner and the team
Scrum methodology is a highly organized development process, and each member is assigned specific tasks to complete the process. One of the main criterion involved with scrum is not to cross or transgress one’s are of work or authority. Each individual involved with the methodology is advised to work within the scope and time frame decided beforehand. However, during the sprint, team members can face problems, or may need specific feedback regarding the acceptance criteria and the level of functionality to be incorporated. For this, it may be required to communicate with the product owner who has all the details.
 

Pitfall
The scrum master comes to know about a particular issue and starts asking team members about the problem. The person than contact the product owner on behalf of the team member for possible solutions or feedback. This is a pitfall. The scrum master is not a project manager. He or she is not supposed to communicate anything with the product owner regarding developmental issues and problems.
 

Solution
Proper channels should be set up and the product owner notified about the issue well in time when the particular problem occurs. The product owner is responsible for addressing the issues and not the scrum master. Moreover, the team members should be instructed to immediately notify the product owner when required, and not waste undue time in discussing alternative solutions amongst themselves.
 

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