The following article is a sample from the full BVOP™ Ultimate Guide and is part of the preparation for the BVOP™'s modern Agile Project Management Certification Program.
Sprint is a fixed period during which planning, real work, daily short meetings and discussions, retrospection (discussion with an analysis of results and processes), and demonstration of the achieved work in front of the client or other business stakeholders are carried out.
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 this need for frequent changes to product requirements.
The simplest explanation for this solution is that Scrum offers product details that only concern the Sprint in which the team is about to start (the upcoming Sprint). A product may be infinitely large. Still, the Product Owner role should focus on collecting development details that only address the parts of the product 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, 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 communicate the team’s issues to 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 (Team Daily 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 that is set, 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 their work 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 work and the direction of development immediately.
Each Scrum event has a specific purpose and a particular timeframe (fixed time). The concept of accurate time-keeping allows participants in an event to be clearer, more precise, and focused on their goals rather than distracted by unnecessary activities or unnecessary discussions. It is the responsibility of the Scrum Master 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 planning with time easier.
Work habits and rhythm are built.
How to choose the length of a Sprint?
The Sprint should be of sufficient duration to provide enough time and some real results and value to the business and the product at the same time, are produced.
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 make this decision on behalf of the Scrum team.
Shorter sprints suggest the faster discovery of obstacles for the team.
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. If one month is spent on the wrong activities, the results of the work can be very regretful.
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 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 much User Stories can develop 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 pressure situations and recalls that such stress is highly likely to lead to burnout, problems, and defects instead of quality work and a stable product.
The Goal of 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 team is doing their current product increment and direct the team. It is also indicated that the Sprint may be terminated if the purpose of the Sprint becomes obsolete. The goal of the Sprint is defined during the Sprint Planning event by the entire Scrum team.
Popular literature disseminates 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 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.
“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 lof 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 of the moment.
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 from the side and 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 him your Sprint Goal.
And even more likely, if you keep defining Sprint Goal, your CEO or client can just read your definition of the goal if you posted it in a public resource.
When defining your Sprint Goal and writing it down, it should be in the most understandable language for everyone involved in the project.
The Sprint must be completed at the end of the last day without waiting for all User Stories to be 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, User Story can be split into many smaller User Stories. Work completed on a product idea during an ongoing sprint can be composed into a tiny User Story, and the remaining work put into other small User Stories awaiting future development.
The Scrum Master role, protecting the interests of the team and all good practices for the benefit of productive work, can discuss with the team whether the team wants 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 smaller User Stories, however, is that the product increment does not contain everything expected, and this must be communicated to 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 communicate these topics to 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 User Story completed than a few started and non-completed tasks.
Ultimately completing User Stories makes it easy to demonstrate an increment that is completed and ready. 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.
Once the Sprint is complete and everything is ready, however, 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.
After the end of the Sprint Review event, the last Sprint meeting follows. Sprint Retrospective. During this “flashback”, the Scrum Master, the Product Owner, and the Development team come together without the involvement of other outsiders (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, Sprint can officially be considered to be over.
The next Sprint begins immediately 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 stopping 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 the role 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 happens by the decision of the Product Owner role, as well as by the influence of the Scrum Master role or the Development team.
With the cancellation of the Sprint, the entire Scrum team gathers reviewing all the work done and not done. The Product Owner role can accept the finished work and suggest it to be added to the increment, and non-completed User Stories usually go back to Product Backlog.