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

[Mrugesh Panchal]

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. 

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

[khannan]

Hello Everyone,

I never realized that we had people from France join our local group -- welcome...!

Mrugesh -- you'll have to excuse me for being picky, but I think there's something amiss about the article.

User Stories (which originated from XP), are simply 1 way of capturing what we're building. Formally, this is a Product Backlog Item (PBI). So,a product backlog may have User Stories, Spikes, Tech stories, Bugs, Defects, etc. etc. This is the power of the framework, where its not being prescriptive.

A product backlog may also have 0 User Stories.
(Hard to imagine for some of us, right?)

Please consider replacing "User Stories" with Product Backlog Items. Otherwise the article reads well.

On another note, your subject line was a bit of a teaser, and didn't explicitly offer any insights to when a Sprint can be canceled? While I do have an opinion / answer, if anyone is interested, I can continue in a subsequent e-mail.

Happy Friday! Have a great weekend!!

Regards,
Nitin Khanna.
PMI-ACP, CSP, PSM (II), PSPO (II), PSD (I), ICP-Agile Coaching