In Scrum, Is It Possible To Cancel A Sprint? If So, When?

The scrum framework and importance of sprints 

Scrum is primarily about dealing with changing market conditions and introducing changes in the product definition while it is being developed. It is very difficult, and in certain cases impossible, to incorporate changes in the features and functionalities linked with the product while its development is currently underway. Traditional development methods such as waterfall do not offer facilities to change the product features once the development has started, since the entire development occurs in stages and it is not possible to reverse the stages, or “undo” the work carried out, nor it is possible to “pause” the development activities and restart them with new ideals and objectives. Scrum makes this possible because the actual development is carried out in sprints which generally last for two weeks. It is very easy to add on, or update the functionalities associated with a particular feature of the product.
 

In scrum, the project requirements are defined in the form of user stories, or product backlog items, which constitute the product backlog. The user stories are arranged as per their priorities and importance in the backlog, and whenever development is to be carried out, a small portion or a set of the backlog, usually the top portion which is more important and carries a higher business value, is transferred to the sprint backlog. During the sprint, each user story contained within the sprint backlog is taken up for development by the team members. After the sprint is completed, the completed user stories are taken up for verification and adjudged whether they are shippable, and are bug free.
 

The main feature of scrum which makes it unique is that it supports development in iterations known as sprints. The scrum framework is specially designed to control the sprint, with its checks and counter checks that help to fulfill the objectives defined in the project. If any new feature or functionality needs to be introduced in the project, it can simply be defined as a user story in the product backlog, and subsequently transferred to the sprint backlog for development. The sprint is the most important activity of scrum, and the framework has laid down many rules regarding how it should be controlled. The rules are mandatory, and should be implemented to get the most out of scrum. 
 

Is it possible to terminate a sprint abnormally before it completes? 

The team members have to complete their development tasks before the sprint ends. It is imperative that the sprint process be time boxed, and completed properly if positive results are to be achieved out of scrum implementation. However, under some rare circumstances, a sprint may be terminated before it can complete its full iteration or cycle. The product owner decides whether the sprint can, or should be terminated.
 

The product owner may terminate the ongoing sprint if:

• The management or the stakeholders change the priority of the user stories taken up for development
• Market trends and changes render the current development as redundant or obsolete
• A technology change may offer newer and more effective ways of working
• A technical solution might offer a faster and more cost effective way of carrying out the product development 
• The management may experience difficult times or a financial crisis, and may not be able to support the development work
• The new product launch may make the current development superfluous and unnecessary

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

Sprint Review Meeting Pitfalls – What Should Be Avoided To Get The Most Out Of Scrum Implementation

The sprint review meeting is held at the end of each sprint. It is very difficult to avail the benefits out of scrum implementation if the review meetings fail to remain effective. It is important to know about certain pitfalls, which can render a review useless and meaningless.
 

Use the review meetings for show casing purposes
Generally, during a sprint review meeting, as per the norm the team members demonstrate the development carried out during the sprint, which has just completed. The tasks and functionalities developed are exhibited to the product owner in the meeting. The PO verifies the tasks developed as to whether they comply with the acceptance criteria and if they are “shippable”. The team is apprised whether the task is accepted as “Done”, or is still incomplete since it does not meet the acceptance criteria as defined in the user story. In many ways, the sprint review is often utilized as a “Show and Tell” meeting, and there is nothing wrong with this. However, if the meeting ends with this activity, it is wrong because the main purpose of the review is not satisfied.
 

The objective of the review is not to focus only upon the items which have been developed during the sprint, and which of them have been accepted as done. It is important to update the product backlog with the items, which have been accepted as done, and transfer those items which have not been developed during the sprint, or which have failed to fulfill the acceptance criteria, to be moved back to the product backlog. It is imperative that the entire review should be conducted in whole, and the product backlog updated appropriately at the end of the meeting.
 

Management and stakeholders “take over” the meeting 

Even though it is not mandatory for the stakeholders and the management to attend the meeting, they can do so if they desire. Scrum supports transparency, and since the stakeholders have invested money into the project, they have a right to know about how the project is proceeding. The review provides an opportunity to find how much development has taken place during the sprint, and how the team is performing. Ideally, the stakeholders should participate as guests and keep a low profile while the meeting is in progress. They should refrain from making comments or participating in an overt manner by asking questions directly to the team members. Moreover, at times the stakeholders tend to focus upon individual team members and keep a track of what they are doing, and how they are performing. This is in antithesis of what scrum advocates. Scrum encourages and promotes team efforts. It is what the team delivers as a whole, which is more important than individual efforts.
 

The product owner should limit the participation of the stakeholders in the meeting so the guests do not overcrowd the meeting place, and the team members have enough room to conduct the meeting. The comfort levels of the team should not be compromised upon. The product owner should also warn the guest to participate in the meeting as passive participants, and not carry out any activity which can disturb the proceedings in any way or manner. Reviews can become meaningless if the management or the stakeholders dominate them.
 

Skipping the sprint review meetings 

There is a general tendency amongst the team members to skip the review meeting if they have failed to complete all the user stories taken up in the sprint backlog, or if they consistently fail to get the user stories accepted as “done” by the product owner. The team believes there is no point in attending the meeting since the user stories are not being accepted.
 

It is important to understand that the purpose of the review is not just to accept or reject the user stories. The main objective is to “review” the performance of the team members and carry out self-correction activity after identifying potential pitfalls. Scrum promotes self-learning, and it is imperative that the team members actively participate in the process and learn lessons from prior sprints so they can auto correct their mistakes. Skipping the reviews can halt the self-correction process, and render the review ineffective.
 

Team members remain absent 

It is very important for the product owner to remain present during the review meeting. In fact, the entire review revolves around the product owner, since the basic purpose of the meeting is to get the user stories accepted or rejected by him or her. Therefore, if the product owner remains absent, and does not attend the meeting, the objective of holding the meeting is defeated.
 

The team members should also remain present in the meeting along with the scrum master. The review offers an opportunity for the team to exhibit its work, and generally each member demonstrates the development carried out. The team members take turns to display their work. As per the norm, each member is supposed to demonstrate his or her development. The review also offers an opportunity to avail the feedback from the product owner regarding the acceptance criteria, and know more about the future user stories to be developed by the team. If the team members remain absent during the meeting, they miss the chance of getting informed about how the future user stories ought to be developed.
 

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

How To Hold An Effective Backlog Grooming Session

What is backlog grooming?
Also referred to as “Story time” sessions, the main purpose of the backlog grooming session is to make improvements in the product backlog and rearrange the items as per new priorities presented by the stakeholders and the investors. Grooming sessions are also held to recheck the product backlog items or the “PBI”s as to whether they contain the necessary information which can aid in developing the user stories in a perfect manner by the development team. The official scrum guide does not venture to define exactly what a backlog grooming session is since the “grooming” can vary from project to project and management to management. The process cannot be standardized to suit all types of projects and all requirements. However, in a nutshell, the grooming session can be used to:

• Write the user stories from scratch if they are not properly defined or described in the product backlog
• Re-prioritize the user stories contained in the product backlog on the basis of recent updates availed from the stakeholders
• Break down large user stories or “epics” into smaller parts
• Estimate or update the story points associated with the PBIs
• Add new or updated acceptance criteria
• Analyze the backlog for technical planning

Product Backlog Grooming In Scrum

Why are backlog grooming sessions necessary?
One of the common problems experienced  by team members while scrum is being implemented, and one which often troubles the stakeholders and the management to a large extent is that the sprint planning meetings seem to last forever, and even after investing proper time and efforts, issues and problems still tend to arise and persist during the sprint activity. It can lead to frustrations for the team members since scrum methodology supports time bound functioning of various constituent processes, and a particular activity cannot extend beyond the time allotted for it to function. Scrum advises time boxing of all related processes, especially the sprint activity. One of the commonest causes why problems occur during scrum implementation is because the product backlog is not properly “groomed” to perfection, and the user stories are not correctly defined or prioritized. It is very important to hold grooming sessions to verify and re-validate the product backlog items from time to time so that a true value of ownership is reflected in the user stories, and the project is completed in a cost effective manner. 
 

How to hold effective product backlog grooming sessions? 
A couple of guideline can help you conduct a meaningful and effective product backlog grooming session:
 

Have a clear goal
During the grooming session, the product owner should maintain an attitude which says “This is exactly what I want to accomplish today” and proceed with that attitude during the session. It is very important to be clear as to exactly for what reason the session is to be held, and what needs to be accomplished from it. The goal of holding the grooming session should be clear, not only to the product owner, but also to the team members participating in the session.
 

Explain the user stories and plan for the next sprint
Carry out the grooming session in a manner such that everyone feels involved and becomes clear about the goals associated with the user stories in the product backlog. The product owner should ensure that each team member has a clear understanding regarding the goals linked with the stories, and if any team member needs clarifications, the product owner should provide them as soon as possible. The product owner should also explain the objectives and specify the goals to be achieved in the next sprint to be carried out after the sprint planning meeting. This helps the team members to prepare for the sprint planning meeting to be held after the grooming session.
 

Limit the participation of stakeholders “chicken” in the session
Stakeholders and investors, often colloquially known as “chicken” in scrum have the right to attend the sessions. The product owner should instruct the stakeholders to participate as passive listeners and not volunteer any opinions, or try to influence the session in any way or manner. The person should further limit their numbers to a bare minimum so that enough space is available to conduct the session in a healthy and easy manner without any hindrances from the guests.
 

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

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:
   o Face-to-face
   o Messaging utilities
   o Internal chat tools
- Discussions can also be facilitated using:
   o Meeting rooms
   o Scrum boards
   o Wall displays
   o Shared tables
 
Distributed teams
- Teams placed in different geographic locations.
  Some of the tools recommended for communication purposes are:
   o Video conferencing tools and hardware/software
   o Instant messaging utilities
   o Chatting utilities
   o Social media tools
   o Shared screens
   o Remote access facilities
   o 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!

In Scrum, Can A Sprint Be Cancelled? If So, When?

Scrum framework and sprint

Scrum development is fundamentally about adapting to changes occurring during the product development cycle. Scrum levies a lot of significance to transparency, distribution of work, and incorporating changes even “late during the development stage”. Each individual associated with the implementation and working of the scrum framework is assigned a specific role. The person is strongly advised to perform within the boundaries specified by the role he or she is supposed to play, and not transgress the area of work under any circumstances. In scrum, the product owner too has a specific role to play, and is responsible for creating and maintaining the product backlog. The product owner has the final word while working out the list of requirements needed to develop the product – the user stories – which form the backbone of any product backlog. Each user story is further divided into individual tasks, which are taken up by the team members. These tasks are developed during the sprint activity. A sprint activity or simply the “sprint” is nothing but a “burst” of development activity undertaken by the team members, which generally lasts from two to four weeks as decided by the product owner. At the end of the sprint, a meeting is carried out which analyses how much development work has taken place, or how many user stories are successfully completed by the team members. So in many ways the sprint functions as the main essence, or the “heart” of the scrum process. Sprint plays an integral part in the scrum framework.

Can a sprint be terminated abnormally before it is completed?

Development teams are always instructed to complete their user stories as well as tasks well within the sprint duration. It is very important for the sprint process to be completed if the management is to achieve positive results out of scrum implementation. However, under some unusual or rare circumstances, sometimes sprints need to be “stopped” or terminated before it has a chance to run its full cycle. It is the product owner who decides if the sprint can or should be terminated or not.

Some of the reasons, which may induce the product owner to terminate the ongoing sprint, can be:

• The stakeholders or the company management changes its priority regarding the product development
• Market trends and/or changes make the current product development redundant or obsolete
• A major technology change may introduce newer ways and methods of working
• A better technical solution may offer a quicker and a more cost effective way of meeting the product development  
• The management or the stakeholders may experience a financial crisis, or may not be able to financially support the development work
• The launch of a new or better product may render the current development work superfluous and unnecessary

Find out more, and subscribe to the permanently free "limited users" QuickScrum tool which can help you in implementing scrum framework in your projects!

How Individuals Not Officially Trained In Scrum Can Still Implement Scrum Projects

Scrum methodology can be effective. It has been specially designed to incorporate the changes taking place in the project definition and product related requirements if and when they change due to the changes taking place in the consumer market, and the whims and fancies of the investors and stakeholders. Even though it eventually helps to reduce the overheads and increase the returns over investment, it can prove to be a trifle expensive when implemented for the first time in a company. Product owners and scrum masters do not come cheap, and so if the management desires to implement the methodology, it may have to make do with temporary substitutes who can act as scrum masters and scrum certified professionals, if the particular business organization lacks in financial resources. 

In a typical scenario, a business concern may plan to manufacture a product, but may be wary regarding its development and outcomes in terms of profitability when launched in the market. Scrum is ideally suited for such venture capital projects, where it may become necessary to curtail the development related expenses and halt the project midway if it is not found to be productive. In such a scenario, the organization may appoint a traditional manager to implement scrum. The person may not be officially trained in scrum, but may be forced to implement it owing to top management decisions. The person may feel at a loss how to go ahead with the project. A couple of pointers may help such a person, who is not officially trained in scrum, to carry out its implementation.

    

Using a good quality scrum management tool or software

A possible way to implement scrum without being officially trained and experienced in its implementation is to use a reputed scrum management software or tool. Of course, it is required to know the basics about scrum methodology and how scrum works, but a lot of time can be saved while catering to the practical details of the methodology and its implementation by using such a tool or software. The software includes a lot of functionality in it, and is often accompanied with a useful user manual or a reference guide which teaches how to use the software, define projects, create product backlogs, and plan sprints. The work of the person becomes a lot easier since he or she may be required to provide the required inputs and let the software do the rest. It may not make you a professional product owner or a scrum master, but it can help to streamline your project flow and get you started.

Get a crash course and implement scrum

Another way to carry out scrum implementation is to become clear about scrum, and how it can be implemented, by reading the official scrum guide and the reference material available. One can also find information pertaining to sample scrum projects and how they can be implemented by browsing the internet. It is the cheapest and the easiest way to get started with the implementation process. The person is not required to know about how Gantt charts and product stories look like. It is also not required to know how they should be correctly defined and presented on paper. 

The idea is to get an overall picture and become clear as to how a particular scrum technique functions, and what it does during the implementation process. Subsequently, the person can use the logic to create his or her particular process and try to implement scrum in a rudimentary fashion. It may not be perfect, but if scrum is properly understood, and it is tried to be implemented in a makeshift manner, it may still bring about some, if not all results desired out of the implementation process.

There is absolutely no substitute for a trained scrum professional. Scrum is a specialized process, and not so easy to learn in the first place. However, if a person is forced to deal with scrum and its implementation, there should be something to start with – an entry point which can pave the correct way for further activity and permanent solutions. The article tries to offer a temporary solution for such individuals.

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. 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!