What is a Scrum Sprint?

Sprint is a fixed period during which planning, development, daily short meetings and discussions, retrospection (discussion with an analysis of results and processes), and demonstrations of the achieved work are carried out.

1. Scrum and changing product requirements
2. The Sprint consists of the following events and processes:
   1. Timeframe
   2. Equal duration of Sprints has the following positive effects:
3. How to choose the length of a Sprint?
   1. Choice of short sprints:
   2. Choosing longer sprints:
4. Sprint Retrospective
5. Starting a Sprint
6. Sprint Goal
7. Sprint Completion
8. Sprint Review event
9. Sprint Retrospective
10. Prematurely stopping a Sprint

Most of the modern products are dynamic, dependent on many factors, and are related to user needs, expectations, emotions, and mood. The development of competition, technology, as well as user habits creates high dynamics in products. Successful teams and companies need to be aware of today’s dynamic business environment.

Scrum and changing product requirements

Scrum offers a solution to the frequent product requirement changes.

The simplest explanation for this solution is that Scrum offers product details that only concern the upcoming Sprint. No matter how big the product is, the Product Owner role should focus on collecting development details that only address the parts of it that will eventually be developed during the upcoming work period.

The Development team, in turn, should also focus primarily on upcoming sprint work. When the Development team has questions and concerns about the User Stories related to the upcoming Sprint, it (the Development team) takes them to the Product Owner role. Sometimes the Development Team may also ask the Scrum Master role, which, however, needs to share the team’s issues with the Product Owner role.

The team is not distracted by ideas that are planned for the future.

Gathering details, describing functionality and product requirements that will not be developed soon will be considered an unnecessary loss as these requirements may change over time based on the feedback provided by product users or stakeholders.

A Sprint is a defined time interval that always has a certain number of days. During this period, the Development team is only working on the planned work for the Sprint.

The Sprint consists of the following events and processes:

• Sprint (Sprint itself, as a complex event)
• Sprint Planning
• Daily Scrums (Daily Team Meetings)
• Sprint Review
• Sprint Retrospective.

Sprints allow the Scrum team to focus on clearly defined and prioritized Product Backlog Items only for a fixed period of time, which is defined and accepted by everyone.

All completed Sprint work is visible to all team members all the time.

The team may try to adapt their efforts during the Sprint.

When a business, the market, and users change and the need to deliver a product is urgent, the visibility of the work helps to adapt and change the direction of development immediately.

Timeframe

Each Scrum event has a specific purpose and a particular time frame (fixed time). The concept of accurate time-keeping allows participants in an event to be clear-headed, more precise, and focused on their goals rather than distracted by unnecessary activities or discussions. It is the Scrum master’s responsibility to ensure that everyone in the Scrum team adheres to the timeframes.

It is up to each Scrum team to decide the length of their Sprint. The duration of the Sprint is consistent, which means that throughout the project (from start to finish), all Sprints must have the same duration.

Equal duration of Sprints has the following positive effects:

The team easily compares the results of the Sprints (work rate, development time forecast).

The team is accustomed to their work capacity and productivity and can make time planning easier.

Work habits and rhythm are built.

How to choose the length of a Sprint?

The Sprint should be long enough to provide enough time and some real results and value to the business and the product at the same time.

Real output and value for business mean that for a Sprint, work (a piece of the project) must be created that is fully completed and can be presented to customers, users, or business stakeholders. Everyone should be able to review and test the finished work and ultimately provide feedback. The result may be approved or may require changes and improvements.

The length of a sprint, according to the official definition in the Scrum Guide, should not exceed one calendar month.

Sprints usually last from one to four weeks.

For guidance, here are some examples that can further help you choose your sprint time.

Choice of short sprints:

You work with technology that quickly and easily produces a real end-result. For example, you use pre-made software, hardware, or electronic components that you only build or assemble and do less finishing activities.

Your product can logically be divided into many small components, modules, parts that you can focus on, and view as standalone elements.

Your client or your directors are impatient and pretty conservative about results. Then it may be politically better to choose shorter periods to satisfy their need for a more frequent review of the outcomes.

Your product and approaches allow you to quickly and easily test your results.

Choosing longer sprints:

The technology used requires more time to achieve a real result. For example, you create complete product technology - software, hardware, or electronic components. You use pure programming languages, you create the elements yourself (through machines, assemblies, etc.).

Testing the result of a sprint (the increment, the finished work) takes a long time and commitment, or depends on external factors.

You have more exhausting processes for delivery, compilation, setup, installation, and other events.

Officially, there are no rules outlined in the Scrum practice regarding the choice of sprint length, and only a brief mention is published about the teams themselves choosing the length of the Sprint. However, BVOP shares the above examples to give you a broader base of ideas.

The whole team must reach a consensus on the length of the Sprint. It is not recommended that anyone makes this decision on behalf of the Scrum team.

Shorter sprints suggest a faster discovery of obstacles for the team. 

Sprint Retrospective

After the work is completed and before you reach the official end of the Sprint, a Sprint Retrospective event is held. The team discusses their work, customer comments, evaluates work, and processes. With shorter sprints, you have more frequent meetings. Problems are defined more often, and solutions are found faster.

Short sprints provide more frequent customer feedback. Thus, the chance of creating unnecessary work or doing something wrong is reduced because the client will identify these irregularities when the increment is demonstrated.

It would make a difference if 1 or 2 weeks were spent on a work that made no sense and served inaccurately, rather than one month, which can result in a very regretful waste of effort and time.

With shorter sprints, the team will likely be able to plan their work more efficiently.

If any project requirement has changed, this change can be identified more quickly and easily.

The most logical time to determine the length of the sprints is at the very beginning of the project when the team is formed and has become familiar with the idea of ​​the project.

Starting a Sprint

Each Sprint starts with a Sprint Planning meeting.

At the beginning of the Sprint, the Development team receives some User Stories (ideas and needs that the customer expects to be made soon), prepared, and prioritized by the Product Owner role.

The development team chooses precisely how many User Stories can be developed through the upcoming Sprint and how exactly the work will be done. Again, no one has to pressure the team to take on more tasks than they can accomplish. The Scrum Master role intervenes in tense situations and recalls that such stress is highly likely to lead to burnout, problems, and defects instead of quality work and a stable product.

Sprint Goal

The Goal of a Sprint is an abstract concept published in the official Scrum Guide, which refers to the idea that the team should set some achievable goals for their work period (Sprint). The goal should explain why the current product increment is being developed and direct the team towards achieving the goal. It is also indicated that the Sprint may be terminated if its purpose becomes obsolete. The goal of the Sprint is defined during the Sprint Planning event by the entire Scrum team.

Popular literature spreads the following purposes of a practical Sprint goal:

• To help prioritize work during sprints.
• It helps to make effective decisions.
• Supports focus during the Sprint Planning meeting.
• Assists teams and collaborations.

Again, these suggestions are quite abstract, like most things in Scrum. The truth is, many teams do not define a Sprint Goal because they do not know what exactly it is for and what to do.

However, let us give you an example to illustrate and discuss how a Sprint Goal can help.

Imagine working on an online platform that allows user registration. You are at the beginning of the project. The Product Owner role has prioritized many User Stories, all associated with user registration related functionality. Let’s set a Sprint goal that will please our customers, users, and all relevant stakeholders of the product.

Sprint Goal:

“Create an opportunity for users to sign up to the platform as quickly, easily, and conveniently as possible without any obstacles or problems.”

This brief plot actually contains a lot of collected information that we need to understand and follow.

We can follow the idea of our Sprint Goal if one of the team members asks the question: “Should I start working on a forgotten password? We have to do it anyway.”

You can quickly answer this question if you remind yourself of the goal of Sprint that the most important thing is the registration form itself, not the side functionality.

Here is another scenario. The marketing department recommends that we add 5 fields in the registration form that users need to fill out.

However, our goal is quick, easy, and convenient registration. We kindly decline and consult the Product Owner role, whether he or she wants to add more fields. If he or she is indifferent, we await feedback from our client. If the client wants more fields, we will eventually add them during the next Sprint. If the client or business stakeholders do not suggest anything like extending the registration form, we have achieved our Sprint goal without distracting ourselves with unnecessary activity. We are reaching our goal.

However, the Sprint Goal may have another valuable application that is not mentioned in the literature.

Imagine your director asking you: “What are you going to do this week?”

Instead of explaining the nature of multiple scheduled tasks, you can simply quote your Sprint Goal.

If you keep defining the Sprint Goal, your CEO or client can just read your definition of the goal if you post it publicly.

When defining your Sprint Goal and writing it down, it should be in the most understandable language for everyone involved in the project.

Sprint Completion

The Sprint must be completed at the end of the last day even if some User Stories are not completed.

Sometimes it happens that some User Stories are not completed.

One idea is to move all incomplete User Stories back to the list of all Product Backlog Items.

The Product Owner role can decide whether to put unfinished User Stories at the top of the Product Backlog. The Items placed above are considered the highest priority. If these User Stories are put back on top, they should be taken on the next Sprint.

However, the Product Owner role may choose to move the unfinished User Stories down the list if he or she believes that for the next Sprint, the team may need to work on something else.

The reason for unfinished work is often that the User Stories are “too big”. This means that there is a lot of work to be done, and the team is unlikely to be able to complete it.

Alternatively, a User Story can be split into many smaller User Stories. The completed parts of it during the Sprint can be composed into one new User Story and all the unfinished parts can become other User Stories, which can be distributed among the next Sprints.

The Scrum Master role, which protects the interests of the team and all good practices for the benefit of productive work, can discuss with the team whether they want to break User Stories into small chunks. After the Development team submits their preferences, the Scrum Master role communicates the decision and choice of the Development team to the Product Owner role.

When the User Stories are split into smaller ones, they are easier to plan and complete.

The problem with breaking down User Stories, however, is that the product increment does not contain everything expected, and this must be discussed with the customer or other business entities.

Scrum has no clear definitions of these issues and cases, so the Scrum Master and Product Owner roles can discuss these topics with stakeholders.

What the entire Scrum team has to be careful about is not allowing many unfinished User Stories. It is often more critical and valuable for both business and product to have a completed User Story than a few somewhat finished tasks.

Ultimately completing User Stories makes it easy to demonstrate a wholesome and fully finished increment. During the inspection (demonstration of progress and the increment), the customer or business stakeholders see developed parts of the product.

Different started and unfinished parts of the product will be of no use to anyone and may only interfere with the accurate assessment of the product increment.

Even if the Sprint is complete and everything is ready, the finished work does not necessarily have to be delivered for demonstration (deployed, installed, implemented). The Product Owner role decides whether the increment (current version) will be presented publicly.

Sprint Review event

The Sprint Review event (meeting) involves the entire Scrum team as well as the roles and representatives of the client or user. During this event, the Scrum team presents the completed work. Scrum has no rules as to who should do this. Usually, the Scrum Master or Product Owner roles present the product increment, but everyone from the Development team is welcome to perform the presentation.

Sprint Retrospective

After the end of the Sprint Review event, the last Sprint meeting known as Sprint Retrospective follows. During this “flashback”, the Scrum Master, the Product Owner, and the Development team come together without the involvement of third parties (any management or customer representatives). The entire Scrum Team (Development Team, Scrum Master, and Product Owner) identifies issues and makes suggestions for improvements for the next Sprint.

After the end of this meeting, the Sprint can officially be considered as finished.

The next Sprint begins on the next business day.

Prematurely stopping a Sprint

A popular term for stopping a sprint prematurely is “Cancelling a Sprint”.

Stopping a sprint means ceasing it and then starting a brand new sprint. Canceling a Sprint should happen in very rare situations and should only be used as a last resort. Various reasons may be the factor for the team to wish to end the Sprint, but the most possible and common cause is a huge and necessary change in product requirements.

The Scrum Master role, as well as the Development team, can offer the Product Owner to terminate the Sprint if they have concerns about the current Sprint and wish to start a new one explicitly.

Only the Product Owner role has the right to terminate the Sprint. The cancellation of a Sprint is a decision of the Product Owner role, which is influenced by the Scrum Master role or the Development team. 

With the cancellation of the Sprint, the entire Scrum team gathers and reviews all the completed and uncompleted work. The Product Owner role can accept the finished work and suggest it is added to the increment, and non-completed User Stories usually go back to Product Backlog.

The following issues related to chapter "What is a Scrum Sprint?" are included in the certification exam. The sequence of questions is presented in the table.
The data is current as of October 4, 2024, 9:12 pm