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!

What Are Scrum Burn Down Charts? Why Are They Needed To Implement Scrum?

What is a burn down chart?
In scrum, a burn down chart functions as a graphical representation to indicate how much development activity is still left to complete the project, versus the time consumed to complete the remaining work. The work related aspect is represented along the horizontal or the “X” axis, while the days or the time factor being consumed is plotted along the vertical or the “Y” axis. A burn down chart is very useful to find out, and predict, when all the work or development activities associated with the particular project will be completed over time. In scrum, burn down charts are very important, and extensively used by scrum masters and the team members to track the status of the ongoing project. In fact, the concept of burn down charts can also be applied in a successful manner to non-Agile or non-scrum based projects.

The burn down chart is generally updated by the end of each sprint. It is updated by the scrum master. In scrum, the X-axis indicates the sprints carried out and planned, while the Y-axis indicates the number of days. The duration of the work carried out and planned, along the Y-axis, can be shown using any unit of measurement such as story points, team days, ideal days, etc as decided by the product owner, scrum master, and the team members.  

Reading the burn down chart
The burn down chart offers a convenient method to monitor the team progress on a daily basis. The horizontal axis on the bottom, the X-axis, indicates the sprint carried out as well as planned sprints, and reflects the total work required to be completed to finish the ongoing project. The vertical or the Y-axis shows the duration of the sprint, usually in days, taken by the development team to design the functionalities of the user stories available in the sprint backlog. On day zero, the first day of the sprint, the total amount of development to be carried out is maximum, since the first sprint is just beginning. As the sprint progresses, the amount of work remaining starts reducing, till it reaches the last sprint when it should ideally become zero. Alternately, a “blue” line can be drawn to represent the “ideal” working conditions with respect to the time taken and the work completed. The red line indicates the actual progress being made, and it should be compared with the blue line to find out how much the team is lacking or advancing with respect to the desired progress. Efforts should be made so that both the lines coincide with each other. This would mean that the project is progressing in the desired and expected manner.

What is the need of using a burn down chart?
Burn down charts are popular because they provide a graphical representation of how the scrum project is planned, and how it is actually progressing. A visual representation is much easier to read and understand, even for people who are not familiar with scrum methodology. The chart is frequently used to extrapolate how the work is likely to proceed over the days, and proves to be useful for estimation purposes, based upon the current level of progress. Many scrum masters consider burn down charts as motivational tools which can be used to prompt the team members to perform as per the sprint plan. Usually the chart is pinned on a whiteboard kept in the same area where the team members carry out development, and it acts as a constant reminder as to how much work is completed and how much of it is still pending. The chart not only acts as a motivational tool, but also helps the scrum master to supervise scrum in a much better manner.  

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

The Dos And Don’ts Of Servant Leader Role For Scrum Masters

What is understood by the term “servant leader”?

Several experts have tried to define the role of a servant leader, as to what it should ideally include, and what scrum masters should do to be considered as good servant leaders. To summarize what the authors have to say about the role, individuals desiring to function as good servant leaders should be compassionate, exhibit humane characteristics, act as a facilitator, and be a mentor for individual team members. Rather than discussing in details about each characteristic, the role can be briefly understood by going through the Dos and Don’ts associated with the servant leader role.

What the scrum master should ideally do to become a good servant leader

• Protect the team and its members from distractions and diversions
• Facilitate the planning activities and sessions
• Encourage team members to participate in sprint reviews and retrospectives  
• Implement scrum methodology and coach scrum to team members
• Help the team to collaborate
• Publicly represent and protect the team’s position
• Anticipate issues and problems likely to occur during the sprint activity
• Discover ways and means to remove the impediments faced by the development team
• Ensure daily scrum meetings are properly conducted as per scrum principles and rules
• Support and encourage transparency while implementing the project
• Properly understand and present the team’s progress to the investors and stakeholders
• When necessary, arbitrate on behalf of the team members

What should be avoided or prevented

·      Provide instructions directly or indirectly to the development team
	The scrum master should act as a facilitator and help the team members to find solutions on their own through guidance, advice, and suggestions.
·      Manage the daily scrum meeting
	Rather than directing the team and providing development related solutions, the person should supervise scrum and ensure the team members follow it properly.
·      Estimate the work taken up by the team
	If the team is coming up with an estimate, the scrum master should not interfere by suggesting or advising as to what the estimate should ideally include. If required, the person can arbitrate on behalf of the team.
·      Remain uninvolved or be unconcerned about where the team is heading
	Always try to maintain a holistic attitude about how the project is proceeding, and how the project can be affected by the work carried out by the development team. One should be clear about the project goals and how the team is currently achieving them.

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

How Can A Scrum Master Successfully Carry Out The Servant Leader Role While Implementing Scrum Framework?

What does the term servant leader actually mean?

Many scrum reference books and articles explicitly state and describe the role of the scrum master as a servant leader. While most of the definitions try to state the same meaning, they can often lead to confusion as to which definition is perfect and should be followed. The importance of a definition comes into the picture once its meaning is properly understood. So, rather than concentrating upon the definition, it would make more sense to understand what the concept really means. In a nutshell, the role of being a servant leader would actually refer to maintaining a positive and humane attitude towards the team members, being sensitive towards their difficulties and problems, and putting in efforts to act as a facilitator so that goals can be achieved in a collaborative manner, with each team member contributing towards the fulfillment of the project in a proactive way. It is important for a scrum master to possess certain characteristics to be a successful “servant leader”.

1. Listening

An individual who is a good listener can also make informed decisions and successfully solve problems. It is important for the scrum master to listen attentively, with an open mind. The person should try to pick up pointers during the daily scrum meetings as to what the team members are really trying to say, and what kinds of problems they are really facing. Some individuals are extroverts and find it easy to speak about their problems in a crowd, and demand solutions from others.  Introvert individuals may find this very difficult to do, and so it would be up to the scrum master to encourage such individuals to open up and be vocal about their problems. Moreover, the person should also try to encourage self-organization and self-learning amongst team members. If the team is facing impediments, it becomes necessary to engage with the issue in a proactive manner and start finding solutions, rather than wait for the team to approach the scrum master with the particular issue. To be a good servant leader, the scrum master should also be a good listener.

2. Awareness

While leading teams, it becomes imperative to develop a holistic view and look at things from a general point of view, rather than be concerned about the micro level issues when a particular issue or problem arises. It is important to look at problems from a higher level and get an overall picture of where the issue is actually heading to before arriving at a consensus with the team members. It is also required to look beyond the role and scope as a programmer or a developer and grasp the problem at its root level before striving to provide solutions. Scrum methodology advocates that the scrum master should not get directly involved with the development work and start directing the team members. At the same time, the servant leader role indicates that the scrum master should act more as a facilitator and help the team members to resolve their problems by providing guidance and advice, even on an individual basis if required. Therefore, it becomes necessary to strike a correct balance between the two aspects of the role.

3. Persuasion

Traditional project managers can be autocratic while delegating their authority. Scrum is in antithesis of autocracy – it supports teamwork and collaboration. The team works as a whole and delivers results. Moreover, the scrum guide indicates a specific role for the scrum master. He or she should primarily supervise, and ensure that scrum is properly implemented, and followed by the team members. Rather than issuing commands and orders, the servant leader role encourages persuasion – discuss and talk with the team members, and encourage them to do things rather than demand action and activities from them. 

Subscribe to the permanent free version of the Quickscrum project management tool to get an idea about how the tool works and what it has to offer.