SCRUM Best Practises

SCRUM is undoubtedly the most popular software development methodology. It involves developing a project in short stages. In theory, each of these should end with the delivery of a piece of the system to the end user. This allows us to remain flexible in meeting business requirements while delivering key functionality very quickly. In practice, due to various factors, this is not always easy. When choosing to work in SCRUM it is worth paying particular attention to the following areas.

Our Team

The SCRUM team consists of 6-7 people with the full range of competences necessary to achieve the set goal. In practice, it will therefore be developers, testers, architects, and business analysts with equal responsibility for the project, regardless of their role. Moreover, the team organises its work and no one from outside should have any influence on how the functionalities placed in the backlog are implemented. Instead, we should keep an eye on motivation by immediately removing obstacles, building an optimal working environment, setting clear goals, and defining a reasonable time frame for the project. It is also worth remembering to keep the team composition as constant as possible between projects. This ensures that its members know how to work together to get the best results. A very important issue in a SCRUM team is communication, especially if the team works remotely. This is because many important details can be missed during a Skype call, or on a Microsoft Teams channel. It is, therefore, worth developing communication guidelines so that critical information is communicated effectively within the team. So it is good practice, for example, to oblige team members to report when obstacles arise or when a problem affecting the work of others is solved. When using software that supports the SCRUM methodology, it is also a good idea to set up email notifications and integration with the chosen communication channel to keep the team informed of changes.


Once the team is formed, we usually move on to working on a list of functionality to be completed, called a backlog. Most often, its development is preceded by a preliminary business analysis of the project to give it a formal framework.


Each item added in the backlog should be defined, adding its detailed description, formal acceptance criteria, priority and point valuation. It can also be immediately assigned to the person responsible for implementation. We can use several different techniques to set priorities, such as:

  • MoSCoW – An acronym for the expression: “Must haves”, “Should haves”, “Could haves” and “Won’t haves”.
  • Business value – The product owner helps set the priority based on the financial value of the function.
  • “Walking skeleton” – A technique most often used to build MVPs. We set the priority so that we have a working application framework as soon as possible.
  • Technological risk – We start with the implementation of the most risky tasks, thus significantly reducing the chances of failure in later stages.

The prioritisation of tasks should be in line with the project objective. We will establish validity differently when creating a prototype and differently when rewriting a system already in operation.

In this way, the backlog of the manufactured product is created at the end:


Highly valued backlog items are worth breaking down into smaller, related tasks. It is good practice to set tasks atomic enough so that it is possible to estimate the time needed to complete them.


This product backlog can be used for sprint planning. It is important to distinguish between the sprint backlog and the product backlog at this stage. We can treat the first one as a frozen list of functionalities to be realised within the next week. The second, on the other hand, can be updated at any time by changing priorities or requirements to correct the course of the project.


Before each sprint, the team must evaluate the different elements of the backlog. This is most often done in the following order:

  1. Prioritising.
  2. Detailing the requirements.
  3. Discussion and questioning.
  4. Team task estimation.

It is useful to invite the product owners to participate in this process. Firstly, they will help prioritise the sprint, and secondly, they can address any concerns on an ongoing basis. This will also make them aware of where the weight of each functionality comes from. Estimates are usually specified as a number of points from 1 to 100 and indicate the level of complexity of the task. If in doubt, the following formula can also be used:

Estimate = (Optimistic + (4 x Most Likely) + Pessimistic)/6

It is important that each member of the team proposes their own value and agrees with the final proposed valuation. Then we should calculate what is the hourly value of one point to be able to give the project a time frame, e.g. 1 point = 4 h. This value will depend on the project in question due to the relativity of valuation. When planning the time frame, it is also good practice to assume that each team member spends 6.5 h per day on project work, and we treat the rest as time for SCRUM elements and risk mitigation.

When planning your sprint, it is also worth remembering not to stretch or shorten it unnecessarily. In SCRUM, it is important to have a rhythm in the team and to keep it constant as it translates into timeliness. On the one hand, it will be better to prioritise and not to pursue several goals at once, as there will be a temptation to add more days to the sprint. On the other hand, it’s a good idea to add some smaller tasks so that you don’t get out of rhythm, for example, in the middle of the week due to a lack of tasks.

Progress Monitoring

When developing software in agile methodologies, we usually do not define precisely what is to be delivered and what the acceptance criteria will be. This makes it difficult to measure the final success of the project. We can reduce this risk by initially analysing the business objectives and requirements in the form of documentation that is the overall system specification. In this way we will define and validate the direction of the work, and by planning each sprint we have the opportunity to delve deeper into individual functionalities. In this way, at the end of each stage we will already have more detailed documentation and, at the same time, working software addressing a certain area of the entire project. Also, we will involve key users in system development and validation from the outset.

It is best to use tools such as Azure DevOps or Jira to monitor progress daily. The team needs to keep it updated with information on active tasks and the time remaining to complete them. In this way, the built-in reporting tools will provide us with information about the progress of the project. Firing charts are most useful in this case:


They tell us how much work remains to be done in a designated sprint or in relation to the total time planned for the project:


Using the charts above, we can detect obstacles causing delays in real-time. We are also better able to plan and estimate the actual completion date.

On the team side, monitoring progress is based on daily meetings, which should take place at the same time. During the 15-minute “daily meeting” each team member answers questions:

  • What was achieved yesterday?
  • What will you be working on today?
  • Are there any obstacles?

This approach keeps the entire team up to date on the status of the project and the progress of the sprint.

A very important and often overlooked element of SCRUM is the retrospective. This is a meeting scheduled at the end of each sprint where the team discusses what went well and what elements still need to be worked on. This is therefore a good time for any suggestions for improvements to enhance efficiency and quality within the team. Often, in an attempt to close a sprint on time, a retrospective is abandoned. This is not good practice, as it misses opportunities for feedback and innovation within the team.


Quality assurance of the produced software is to some extent enforced by the SCRUM methodology. In day-to-day work, developers and testers work together daily, usually in the same room. This enables us to ensure appropriate quality assurance standards already at the implementation stage. Very often, however, the end-user is not able to see the results for the first few sprints. We can solve this problem by creating interactive mock-ups at the analysis stage, for example using Axure. This way, we will test the functionality before it is implemented. This allows us to gather feedback from users and allow them to adapt the subsequent implementation to actual business needs. To improve the quality of the code, it is worth introducing appropriate policies in the team. This could be, for example, requiring peer review of changes sent to the repository. This eliminates logical errors and possible occurrences of poor code quality. It is also worth using techniques such as continuous delivery and automated testing. They ensure that with every change, we first test the system and then deliver it to the end-user as quickly as possible. Then we have a chance to immediately catch possible errors and verify new functionalities.


SCRUM will work well wherever we do not yet have precise business requirements. An adequate preliminary analysis will provide direction and monitor subsequent progress. When choosing agile software development methodologies, it is worth betting on an experienced team and proven tools. In this way, we can achieve maximum productivity and fast delivery times, while gaining in the quality of the final product. 

Share on linkedin
Share on facebook
Share on twitter

You may also find interesting:

Product Design Sprint

Design Sprint is a process of business problems solving developed by Google Ventures. It was created to help start-ups build better products. We adapted this method to the requirements of big organizations.

Design-Driven Innovation

Innovation is often about changing the meaning of what a product or a service is and what it offers its users. This is the core of the design.

UX & Visual Design

Interfaces, processes, and ecosystems, improve customer journeys, help to increase sales, and provide better customer service. We combine business and users’ needs to create digital products that make money.

Scrum at a glance

SCRUM has become the dominant approach to organising project work. The high variability of the economic and legal environment forces companies to increase the speed of adaptation.

Contact us