Scrum has prescribed a set of events that are essential to ensure consistency in the process. These are timeboxed events, which means every event has a maximum duration that can't extend. The design of these events is such that it enables transparency and inspection. In this article, we will discuss the most critical event - Sprint.

• What is Sprint?
  • It's Characteristics
  • Canceling a Sprint
• Common Sprint Questions

What is Sprint?

We know that Scrum is an iterative approach to software development. Each of these iterations is called Sprint. It is a short, timeboxed period when a Scrum team works to create a Done, usable, and potentially releasable product increment. These iterations act as mini-projects of a large project.

Sprints are at the very heart of Scrum and agile methodologies, and getting it right will help the agile team build better software with fewer issues.

What are Sprint's Characteristics?

Let's look at some of their key characteristics:-

Timeboxed

Timeboxing simply means to limit the maximum time an activity can take. It's the core concept of a Scrum model. Therefore all the events that Scrum prescribes are timeboxed. Timeboxing of Sprints also takes place, and they have fixed start and end dates. Typically, a Sprint duration is 1, 2, 3, or 4 weeks, and this varies from organization to organization. Within this timebox, the Scrum team has to finish the agreed set of work.

What is the requirement of timeboxing? Why can't we have a 3-month Sprint like in traditional project management? Let's understand some of the advantages of Sprint timeboxing, which should answer these questions!

• Establishes a Work in Progress Limit: A work in progress task is the one which started but didn't finish. In traditional project management, there was a big laundry list of such work items that have been pending for months. Failing to manage these WIP tasks can have severe consequences for budget, quality, and timelines. As timeboxing of Sprints happens, these WIP tasks cannot go beyond their duration. The team will pick only the work that they are confident of finishing within Sprint.
• Forces Prioritization: As Scrum is iterative, we get to chose what work needs to accomplish every Sprint. It would happen every 1-4 weeks, depending on Sprint duration. It results in the Scrum team to prioritize their work. As a result, the most important functionalities are the first to be picked.
• Demonstrates Progress: In Traditional project management, the progress was measured, but couldn't demonstrate often. A development phase would run for 3-4 months, and actual progress would only show at the end of the development phase. However, Scrum allows displaying accomplished work at each Sprint. The Scrum Team needs to demo the work done to the Product Owner, and he needs to accept the deliverable before the Sprint closes successfully. It also helps in getting quicker feedback and early detection of any issues.
• Avoids Gold Plating of Work: What is Gold Plating? It means intentionally adding extra features that were not part of the original scope. It often pleases the clients. But this sounds like a good thing to do - isn't it?

A PwC study of over 10,640 projects analyzed that only 2.5% of companies complete their projects 100% successfully. The other projects either run over time, over budget, or drop some agreed on features. Do you now see why shouldn't we do gold plating! The projects are already struggling to complete what was agreed on, so there is no point in doing work that was not part of the scope.

A Sprint is timeboxed, and it has defined goals, so gold plating becomes difficult. It helps the team to focus only on the scope that was part of the Sprint plan.

• Predictable Outcomes: A timeboxed Sprint improves predictability. It's easier to predict what will happen in the next 1-4 weeks as compared to something which happens six months down the line. It's easier to say that we will complete Login and Registration functionality in Sprint 1, Cart Functionality in Sprint 2, etc. Now compare this by saying that we will complete the eCommerce website in the next six months !!
• Motivates Closure: A timeboxed Sprint with a defined end date motivates the Scrum team to complete the work. Imagine that the team is working on login functionality, and they run into issues. In Scrum, they will make all the efforts to close out the issue. However, in traditional project management, it's easier to move on to other functionality. It results in several tasks that remain Work in progress.

Short Duration

We know that Sprints timebox, but even a three-month timebox can exist. So why does Scrum prescribes that a Sprint should not be more than a calendar month? Let's discuss some of the advantages of keeping its duration short.

• Easy Planning - Imagine that you are doing a project where you have to create a new eCommerce website in 6 months. If you need to plan for this entire six months, it is going to be pretty tricky. You need to know all the dependencies, third party schedules, etc. However, if you just need to plan for the next 1-4 weeks, it's easier, less time consuming and much more accurate than traditional project management.
• Quicker Feedback - Each Sprint creates a potentially releasable Increment of the product. It means that the product owners and stakeholders have the opportunity to provide feedback within every 1-4 weeks. Therefore, if anything is going wrong and needs a course correction, it can be taken up quickly. Compare this with traditional project management, where business users would usually look at the application during the UAT phase. Naturally, by this time, we are already too late to do any course correction.
• Better Return of Investment: We know that each Sprint would release a potentially releasable increment of project (Yeah - we are telling this the zillionth time ! ). It means that we have an opportunity to release a feature much early as compared to traditional cycles where we had to wait for the entire project to finish. It helps to get the benefit of new work as soon as it finishes.
• Capping of Errors: Imagine that you are developing an eCommerce website, and after six months of work, the product rejection happens in User Acceptance Testing! How long will that take to course correct? It will put a lot of stress/pressure on the team to make it work. Now compare this with Sprint - Even if everything goes wrong, it's worth only 1-4 weeks of effort. It is still easier to correct and get the project back on track.
• Frequent Checkpoints - As Sprints are timeboxed, the work needs to complete in 1-4 weeks duration. As such, the team needs to have numerous checkpoints to gauge the progress. There is a daily Scrum meeting with the team. There are checkpoints at the end of the Sprint (Sprint Review and Retrospective) where the reviewing of work and identification of improvement opportunities takes place. We will discuss these checkpoints (called Ceremonies) in detail in subsequent articles.

Consistent Duration

Consistent duration is another crucial characteristic of Sprint. It means that if you have a 1-week Sprint, then all the Sprint in the project will be of 1 week. Why do we do that? Let's discuss some of the advantages of having a consistent duration.

• Rhythm and Consistency- If the Sprints are of the same duration, then it's easier for the project team to get into a rhythm. They get used to the cadence. The usual story points are similar in each of the Sprint, so the level of effort is consistent.
• Ease of Planning - A consistent duration Sprint will have similar story points (amount of work), which makes it easier for the Scrum team to plan out the work. Imagine if Sprint 1 is of 4-week duration, but Sprint 2 is for one week. If there is any slip over from Sprint 1, then it might not fit in Sprint 2 at all. It will make the life of Scrum master difficult. A fixed duration also helps in quickly coming out with the number of Sprints (assuming there is a fixed release date). In the case of variable duration, a lot of effort will be needed upfront to figure out the number of Sprints, and the logic behind it.

No Goal Altering Changes

One of the key characteristics that make Scrum so successful is the concept of No Goal Altering changes. Before we start the Sprint, we define the goals for it. The goals are in the form of a product increment that potentially release to production. If you are making an eCommerce website, the goal could be to create login and Registration functionalities, which will allow users to register a new account and log in using that account.

Once the Sprint starts, it's not allowed to make changes, which can result in the Sprint not accomplishing its goals. It helps the team to focus on the work without any distractions from changes.

Does that mean we cannot make any changes? Well, Scrum encourages closely working with the Product owner and taking regular feedback. It could result in some suggestions and improvements. Minor feedback that does not impact the Sprint goal can be incorporated. However, anything significant cannot include. Let's understand it with an example. Consider that you are making login and registration functionality for an app. The product owner has requested some additional validations in the registration form (E.g., Add criteria that if First Name should not have special characters, and phone number field should accept landline numbers as well) These are smaller changes. They would not affect the goal ( which is to create login and registration functionality).

Now consider another feedback, where the Product Owner has asked the implementation of finger scanning for login. It is a significant change, and it could potentially result in a goal not being met. As such, the Product owner will need to park this functionality for a future Sprint.

Canceling a Sprint

We understood the benefits of not altering the goals, but not everything can go with defined rules. The Scrum Team needs to be practical and not just go by the rule book. What happens if the work increment done for Sprint 1 results in a significant production bug? The current team should work to fix it, or should we continue to work on Sprint 2? The answer is obvious - the team has to pick up the production issue. Now, this may impact the Sprint goal. In such cases, it's possible to reduce the goal (Remember - you cannot lower the quality !). So instead of both login and registration, the product owner may decide to go ahead only with registration.

However, in some rare cases, the goal might not make any more sense. Like, when the requirement of the functionality diminishes, or a competitor comes up with better features. In such cases, there is no point in continuing with the Sprint. It needs to terminate. Remember - Only the Product Owner has the authority to cancel the Sprint.

Cancellation has visible impacts - both from the budget and timeline perspective. The analysis of the developed deliverable happens to see if it's possible to re-use any of it, and re-estimation of the unfinished work takes place. Sprint retrospection takes place after cancellation, where the team gathers to discuss the prevention of its occurrence, and take the next steps to prevent any future cancellations.

Common Sprint Questions

We have discussed a lot of topics in this article. Let's now try to answer some of the common questions that people have on Sprint.

How do we decide Sprint duration? What is the definition of the best duration?

Scrum prescribes that Sprint duration should be less than one calendar month. Typically teams keep the Sprint duration as 1,2,3 or 4 weeks. The duration solely depends on the work we are trying to accomplish. Remember - The Scrum suggests that each Sprint needs to have a potentially releasable Increment of the product. Therefore, if we are making a brand new website, the features might take a bit longer to implement, and a four weeks Sprint might be more suitable. However, if we are only doing a UI redesign, then a weekly Sprint might be best suited.

Is it necessary to release the feature to production after every Sprint?

We have read several times that we create a releasable work increment. However, this doesn't mean that we can only release at the end of the Sprint. We can release a feature as often as we want during that time frame. On the other hand, it's also possible that we don't release anything to production after Sprint end. All this depends on what product we are developing. The whole idea is to ensure that we have something "verifiable" and "releasable" at the end of the Sprint, and not necessarily the fact that we need to release it to production.

What happens to Sprint duration when there is a public holiday?

Let's say that we have 2-week Sprints in an organization, and we have a public holiday. In such cases, we still keep it for two calendar weeks, but from a work perspective, we only plan for nine days of work instead of 10 days. We don't extend the Sprint by a day to accommodate a full ten days' worth of work.

Well, there could be several other questions like who all work in a Sprint, what their roles are, and how do we plan it. We will cover all these questions in subsequent articles.

Happy reading!