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:
- Detailing the requirements.
- Discussion and questioning.
- 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.
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.
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.