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 functionalists 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 functionality 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 stoppable, and are bug free.

The main feature of scrum which makes it unique is that it supports development in iterations known as sprints. The 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. Read more https://www.apsense.com/article/in-scrum-is-it-possible-to-cancel-a-sprint-if-so-when.html

                  "Please visit http://www.quickscrum.com to download the Quickscrum tool" 

The Purpose And Goals Of Carrying Out Product Backlog Refinement In Scrum

The official scrum guide mentions about carrying out routine maintenance activities to update the product backlog, or to carry out the product backlog refinement. The exact time to be invested in the grooming activity depends upon the management, and how scrum is to be implemented in the project. A rule-of-the-thumb followed is to put in approximately 10% of the time utilized during the sprint activity, into the grooming activity. It is important to be clear regarding some of the aspects associated with product backlog refinement.

Purpose and goals of carrying out the refinement

The primary reason why the product backlog should be refined is to update or rebuild the backlog so that it remains consistent with the requirements provided by the stakeholders with regards the new features and functionalities to be included in the project. Another reason is to review existing user stories or product backlog items and decide whether they are still useful or pertinent from the development point of view, and to update the acceptance criterion and the explanation detailed in each PBI.  

It is recommended to use the “DEEP” method - detailed appropriately, estimated, emergent, and properly ordered – while prioritizing the user stories within the backlog. Larger stories or epics should be systematically broken down in to more manageable smaller ones, proper estimation by assigning relevant story points to the PBIs should be carried out,  user stories should be rearranged as per the new priorities,  and the queries regarding the development of user stories during the sprint should be effectively answered by the product owner. Whenever a meeting is planned to refine the PBIs, the objective should be to carry out enough refinement work so that it lasts for at least three future sprints.   

Duration and frequency of the grooming activity

Each activity and meeting is time boxed in scrum. Following the same principle, the product backlog refining or grooming activity should be time boxed too. However, in practice, there is no pre-designated activity or a meeting for planning and carrying out the product backlog refinement activity in the same manner as the sprint planning meeting and the sprint retrospective meeting is held. Backlog grooming is carried out more as a routine activity than anything else in scrum, and the guide does not exactly specify how much time or efforts should be invested in the activity. Perhaps a possible reason could be that the product development and creation of product backlogs vary from project to project, and it is difficult to standardize how the grooming activity should be carried out since the size and nature of the product backlog cannot be adjudged. Read more on http://ezinearticles.com/?The-Purpose-And-Goals-Of-Carrying-Out-Product-Backlog-Refinement-In-Scrum&id=8381136

       "Please visit http://www.quickscrum.com to download the Quickscrum tool" 

The DEEP Method Used For Product Backlog Grooming – How To Prioritize the Product Backlog Items In Scrum

It is very important to prioritize the product backlog from time to time so that it remains updated, and “healthy”. The DEEP method used to refine the product backlog items can be understood as follows:

1.    Detailed appropriately

User stories to be taken up for development soon should be properly understood and taken up for development in the upcoming sprint. The user stories which are not to be developed on an immediate basis can be mentioned briefly and described with lesser details.

Generally, the user stories or the product backlog items having a higher priority should be developed first, followed by less important ones. The smaller and more detailed user stories, which a have higher business value should be place on the top, followed by those which have lesser business values and priorities. Epics and large user stories should be broken down in to smaller, more manageable ones, and taken up for development in succeeding sprints. If the entire product backlog is to be detailed in each grooming session, it would take too much time, and even after investing it, the priority can change in the subsequent refining sessions. Therefore, it is not advisable to carry out the grooming session in totality, each time the session is conducted. The objective should be to target the most important user stories based upon the feedback availed from the stakeholders and detail them as per the new priority. The PBIs should be shifted up or down in the order, and larger epics can be broken down into smaller stories and reinserted in appropriate places within the backlog as per the need.

2.    Estimated

Besides containing the product backlog items or user stories, the product backlog is an important and useful scrum planning tool. It should include estimation in terms of story points for each backlog item.

Estimation is possible in scrum when story points representing the degree of importance are associated with each product backlog item. It is very important for the user stories to have a certain business value associated with them when they are included in the product backlog. The product owner works out how the story points should be allotted to each item in the backlog. The story points, or the estimate is very useful in planning future sprints, and while creating the burn down charts while a sprint is currently being executed. It is essential for each user story to have a priority, at least when they are important, and to be taken up for development on an immediate basis.

3.    Emergent

The product backlog is dynamic in nature and changes with time as the project develops. AS more information is availed, new user stories can be added, existing ones updated and reprioritized, and redundant ones removed.

In practice, a product backlog is never static, and will change over time. As more is learned, user stories in the product backlog can be added, updated, or removed depending upon the feedback received from the stakeholders and investors. Moreover, the development team should carry out routine perusal and remain conversant with the product backlog so they find it easy to understand the user stories when they are taken up for development. The members should demand explanations about items not clear to them, and the product owner is supposed to resolve the queries as soon as possible in a satisfactory manner. The product backlog should complement the vision seen by the stakeholders and the product owner, and fulfill the expectations of developing a shippable product which is profitable.

4.    Prioritized

The product backlog should be properly arranged as per the priority of the user stories, preferably at all times.

Although scrum advocates that each item be properly estimated before it can be added to the product backlog, in practice, this seldom happens. When the product backlog is initially planned, the product owner understands that some of the stories need to be developed because they are essential and needed to complement the product, or make it shippable. However, quite often, he or she fails to receive proper feedback from the stakeholders regarding their importance, or receives it at a later time. In such circumstances, the common practice is to include the user story in the backlog, and wait for further information to pour in so a priority can be assigned for the particular story. Scrum advice this should not ideally be done, and information should be availed to prioritize the item before it can be taken up for development. 

                             "Please visit http://www.quickscrum.com to download the Quickscrum tool" 

Source:- http://computersight.com/programming/the-deep-method-used-for-product-backlog-grooming-how-to-prioritize-the-product-backlog-items-in-scrum/

Explanation Of Scrum Burndown Charts – The Plotting, Requirement, And Purpose Of Burndown Charts

What is a burn down chart?

A burn down chart is an important tool in scrum. It provides a visual representation about the progress achieved in a sprint while it is underway. They are very common and extensively used by scrum masters while scrum is being implemented in a project. The quantity, or the amount of work remaining, in the form of pending tasks, is typically exhibited in a burn down chart. The chart is simple and easy to understand, even by people who are not familiar with scrum methodology. Burn down charts are very useful for estimation purposes, and are essential for determining the sprint velocity – the rate at which work in the form of user stories is being completed by the development team – and planning the sprint release.  

Plotting the burn down chart

A burn down chart can be plotted by including the work remaining in the form of story points along the vertical Y-axis and the working days along the horizontal X-axis. The pending work is typically represented in story points – a unit of measurement to calculate the importance and priority of user stories in the sprint backlog – instead of user stories. The reason is user stories are broken down into tasks during the second half of the sprint planning meeting by the development team. It becomes difficult to read and understand the chart if tasks are represented along the Y-axis. User stories are descriptive in nature, and do not have a number or a value associated with them, so it becomes difficult to estimate them. Therefore, the story points, which are numeric values associated with each user story, are used for plotting purposes. Know more on http://ezinearticles.com/?Explanation-Of-Scrum-Burndown-Charts---The-Plotting,-Requirement,-And-Purpose-Of-Burndown-Charts&id=8371905 

          "Please visit http://www.quickscrum.com to download the Quickscrum tool"  

  

Reasons for Carrying Out the Product Backlog Grooming Activity

What is product backlog grooming?

The main objective of the backlog grooming session is to improve the product backlog and rearrange the user stories or the product backlog items in accordance to the new priorities determined by the stakeholders or the team members. Grooming sessions can also be held to verify the product backlog items whether they have the information necessary to develop the user stories in a more efficient manner. The scrum guide does not try to define what a backlog grooming session actually is because the “grooming” activity may vary from project to project. It is difficult to standardize the process so that it can suit all types of projects. The grooming session are generally held to:

·       Write or rewrite the product backlog items or user stories if they are not properly stated or described

·       Reschedule or reprioritize the product backlog items based upon the recent updates provided by the stakeholders

·       Segregate epics or large user stories into smaller and more manageable ones

·       Re-estimate the story points linked with the user stories

·       Update or add new acceptance criteria to the user stories

·       Analyze the product backlog for planning purposes

Different reasons why the product backlog is refined

The product backlog can be rescheduled or refined for a number of reasons depending upon the changes occurring in the market conditions or new features demanded by the end users. At times, it becomes necessary to weed out less important tasks and replace them with effective ones. The product owner may decide to reprioritize the backlog if he or she feels some of the user stories need to be developed on a priority basis. Usually, the product backlog grooming activity or product refinement is carried out because of three main reasons:

1.    Refinement carried out by the stakeholders

As the market conditions keep on changing over time and new competitive products are launched, it becomes necessary for the stakeholders to do away with some of the functionalities in the product which have become obsolete and are no longer needed. It is meaningless to spend time and efforts over features which are not likely to score for the product in the market, and which no longer have a selling value. The investors and stakeholders remain in touch with the ongoing market trends, what the end users require, and how the selling value of the product can be increased by introducing new set of features and functionalities while the product is being developed. The stakeholders may decide to “overhaul” the project by removing some of the features and functionalities, and replace them with new ones, which have added market and selling values.

2.    Informal product backlog grooming

One of the important objectives of carrying out the product grooming activity is that the team members too attend the grooming sessions, and it offers an opportunity for the product owner to explain the user stories to the development team. The product owner takes the opportunity to describe and explain the new set of product backlog items to the team members and answer questions regarding the business values of the user stories. It is a great way of understanding what the product eventually focuses to do when it is launched in the market and how it is supposed to behave when fully developed. Generally, the grooming sessions are succeeded by the sprint planning meetings, and the team is able to prepare in advance for the planning meetings in a more meaningful manner. Since the team members become more familiar with the exact functionality associated with the user stories, it becomes easy for them to segregate the user stories into development tasks during the second half of the sprint planning meeting.

3.    Periodic refinement carried out by the team members

It is important to carry out “routine maintenance work” and keep the product backlog “in shape” so it becomes easy to plan the sprints. As the sprints progress and development is carried out during the sprinting sessions, some of the tasks are completed and new functionality is developed. At time, the functionality developed can be shared with other resources to be developed, and it is important to identify such resources so duplicate or repetitive development activity can be avoided and time can be saved. The grooming session help to weed out the repetitive tasks and get the backlog back into “shape”. It also provides an opportunity to the team members to ask for clarifications and demand explanations for the stories they find it difficult to understand to the product owner.  

                "Please visit http://www.quickscrum.com to download the Quickscrum tool"  

Source:- http://www.apsense.com/article/reasons-for-carrying-out-the-product-backlog-grooming-activity.html

The Product Backlog in A Nutshell: For Scrum Beginners

The Product Backlog

In scrum, the product backlog consists of all the user stories, or the set of requirements which are essentially required to manufacture the product in totality. By totality, we mean a product which possesses all the attributes as requested by the end users so that they can use it in an effective and meaningful manner to carry out their tasks or activities. In reality, the user stories are the same as product backlog items. While the product backlog item or the “PBI” is the actual terminology recommended and used by scrum, in simple language it is often referred to as a “user story” by the team members. In practice, the product to be developed is actually owned by the stakeholders or the investors who have put in money into the project. Since their role is to “own” and “decide” about what kinds of features and functionalists should be incorporated into the product, it is not practical for all the stakeholders to carry out the development process by addressing the team members on an individual basis. It is not practical to do so. Therefore, they appoint a person who acts in the capacity of a “product owner” and who represents their interests while the product is being developed and scrum methodology is being implemented in the project. 

Product backlog

At the onset when a scrum project is planned, the product owner first of all clearly understands about the features and functionality to be provided in the product. Subsequently, he or she breaks up the entire product into its constituent parts, which can be later “assembled” to “remake” the product when all the constituent parts are developed individually. The parts actually form the PBIs in the product backlog. While the product backlog is being constructed or compiled, it is necessary to determine how important the user stories are as far as the final product is concerned. While some of the functionality associated with a particular user story may be very important, quite a few of them may not be so important from the end user or the market point of view. It becomes necessary to prioritize the user stories depending upon what kinds of functionality and features they possess. The activity of prioritizing the user stories or the PBIs is done by the product owner.       

Moreover, the product backlog contains the explanation and description of the functionality linked up with each user story. It is specifically explained in what manner the user stories are to be developed by the development team members during the sprint activity. Many times, the user story can also contain the functional and non-functional aspects needed to understand the requirement in a proper manner. The product backlog is very critical, and forms the “heart” of all scrum related activities. It should be carefully prepared by the product owner. 

                       "Please visit http://www.quickscrum.com to download the Quickscrum tool"  

Source:- http://www.apsense.com/article/the-product-backlog-in-a-nutshell-for-scrum-beginners.html

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.

             "Please visit http://www.quickscrum.com to download the Quickscrum tool"  

Source:- http://www.apsense.com/article/the-dos-and-donts-of-servant-leader-role-for-scrum-masters.html