Recommendations

Visual alerts can be created on digital dashboards: we will put an alert in the “Ready to develop” column that will be displayed when this column has fewer tasks than twice as many people working. This will help the technical leader to see that he has to estimate more tasks so that he can develop.
On the other hand, it is recommended that a person not have more than 2 tasks “in progress”. We will also set an alert when the number of tasks exceeds twice the number of developers.
We also recommend that all participants and stakeholders in the software project have access to the dashboard view..

Estimating

As a technical leader you must be in charge of estimating and analyzing the tasks to be performed. To do this, we will stop at the tasks created in the backlog column and estimate based on how we can provide new functionalities to the project, but always prioritizing what the client needs most.
When we begin to estimate a task, the first thing we must recognize are the acceptance criteria. These are the essential functional features that must be performed to complete the task.

Once we have the acceptance criteria defined, we must estimate them. For this we will use the following table:

This table will help us indicate the effort of the acceptance criterion based on SIZE (number of things that need to be done) and COMPLEXITY (the difficulty of those things).
For example:  If we have to create a new table in the database, we assume that we have 1 SIZE (only one thing to do) and the difficulty will depend on how this new table affects the database: if it were simple we would say that COMPLEXITY is 1 and the result of the effort would give us 1. Once we have estimated the acceptance criteria, the total effort of the task will be the sum of all the efforts. 

In our FLEXIN Teams platform, the system allows, through artificial intelligence, to know how long it can take to complete a task, taking as an example tasks previously carried out with the same efforts in the acceptance criteria.

Calculated

This section is specific to FLEXIN, since normally, in agile methodologies the real time that a task may take to be completed is not usually calculated. This is a great advantage that can be used by any freelancer to calculate any budget or by large companies to evaluate their costs beforehand. The way we calculate time is based on previous experiences from previous tasks.

This functionality is already integrated into our FLEXIN Teams platform thanks to artificial intelligence, which is why it is highly recommended to use it.

If it is not possible, what we do is the following: we look for previous experiences that have had estimates equal to the task we are estimating, but not based on the total effort, but by comparing the estimates on each acceptance criterion (number of things + difficulty ). ). For example: if we have a task with an acceptance criterion of a COMPLEXITY of 2 and a SIZE of 3, we will not look for a task that has a total effort of 5, but we will look for a task that has an acceptance criterion with the same COMPLEXITY and SIZE it is.

Once that task is found, we will see how long it took to complete and we will use it as an approximate completion time for the task we are estimating.

Daily

It is a daily meeting of no more than 15 minutes in which all the developers on the team must be present and each of them has to answer three questions:

• What I did yesterday? 
• What will I do today? 
• Do I have any impediment or difficulty? 

Demo

All those interested in the project participate. Generally this is where the functionalities developed in the last period are presented. The more people participate, the better it will be, since there will be more opinions and proposals for improvements. This meeting is to make product deliveries. They can occur when a milestone determined by the client is reached or deliveries can be agreed upon every certain time.

At FLEXIN Kanban, the technical leader will perform the following tasks:

• Analyze the functionalities needed for the application and pass them to tasks on the board

  It is recommended to go towards this in sections or small parts of the application, since you have to do a descriptive analysis of each task in a technical way. For example: if the task consists of creating a table in a database, indicate the name of the fields and their types. Thanks to the technical description, the developer will be clearer about what he has to do, resulting in much less confusion.

• Create task acceptance criteria

  This is the most important part of the technical leader, since we not only have to create the acceptance criteria for the tasks, but also estimate them to be able to move the task to the “ready to develop” column.

• Lead daily meetings

  If possible, involve the client so that they have a daily vision of the development.

• Review the task once completed by the developer

  It is necessary to verify that the acceptance criteria are met and that the functionality is as requested. If you have a QA team, you should try to deliver the new functionality as quickly as possible, regardless of whether it is in the same development environment.

• Deliver new features to the client

  Always through versions so that the client knows what is being presented to them. If you have a DEVOPS team, the technical leader must give you instructions on how to deploy the application.

If you have a quality team, it is best to create a column between code review and customer approval. It is important to have the QA team as quick and accessible to new features as possible, so that when the client sees them they are already approved. It should also be noted that the QA team should be able to test functionality in the development environment and do regression testing in the pre-production environment.

If you have a DEVOPS team, it is advisable to have two environments prior to production. A development environment, which should not have continuous integration so that each developer can upload what they need to test, and a pre-production environment that continuously uploads the latest generated version. 

Description

FLEXIN Scrum is an optimization of traditional Scrum, which has a radical change, removing the scrum master and giving a lot of responsibility to the technical leader to be in charge of applying the work methodology and also to support the development team. . That is why it will NOT be easy to find a professional with these well-developed disciplines. What is usually done is to prepare the technical member with greater analytical capacity and technical skills and instruct him on the methodology, if he does not know it.
In FLEXIN Scrum, all Scrum meetings are respected, but modifying the participants and the ways of carrying them out.

How does it work?

In FLEXIN Scrum we have a Backlog, which is where the tasks to be carried out will be, a cycle where tasks will be placed to be carried out and also a product that will be incremented at the end of each iteration of the cycle. Each iteration is called a Sprint.
The technical lead will be present at all stages, help the Product Owner create and estimate tasks, provide technical support to developers and can write code if required.
To begin the sprint, two previous meetings will be held: one for refinement, which is where the tasks are analyzed and estimated, and another for planning, to know which of the estimated tasks will be carried out in the sprint. Once the tasks are planned, the developers commit to completing them within the duration of the sprint.
The sprint is carried out with a demonstration meeting of the completed tasks and after that, another retrospective meeting, to strengthen the team and evaluate improvements in performance.

Recommendations

To track the sprints, digital platforms such as JIRA are used, which we highly recommend since it has integration with our FLEXIN Teams platform and thus uses the pre-estimation functionality, where, thanks to artificial intelligence, it provides approximate details. of hours of task completion, to match them with the team’s hours in the sprint.
If there is an architect on the team, he or she should be coordinated with the technical leader and participate in refinement meetings, but ideally the technical leader should have the ability to work on the architecture of the application.

Refinements

The Product Owner and the technical leader will be present at this meeting. The purpose is to analyze and estimate the tasks that are already ready to be carried out. It is important to analyze a larger number of tasks than the team could do in a sprint in case development is going very well.
The technical leader must create the acceptance criteria for the analyzed tasks and in turn must estimate them in effort for which he can use the FLEXIN Teams platform.

Planning

The Product Owner, the technical leader and all the developers on the team will be present at this meeting.
The purpose is for the technical leader to present the analyzed tasks so that the developers can discuss the estimates and indicate the tasks that will be performed in the sprint. It is important that developers commit to finishing the sprint tasks, as this is the key to this methodology.

Daily

It is a daily meeting of no more than 15 minutes in which all the developers on the team must be present and each of them has to answer three questions:

• What I did yesterday? 
• What will I do today? 
• Do I have any impediment or difficulty? 

Demo

All those interested in the project must participate in this meeting. Typically, this is where the new addition to the product, which was developed in the sprint, is introduced; The more people participate the better it will be, since there will be more opinions and proposals for improvements. It is done when the sprint time is met. If this meeting is postponed it is considered a breach of the same; It would also be considered a breach if any of the tasks had not been completed. 

Retrospective

It is done after the sprint demonstration. Only the Product Owner, the technical leader and the members of the development team participate. It is used to give feedback on the sprint, seeing what the good aspects have been and the aspects that should be improved. Technical or human improvements could also be evaluated to improve team harmony. 

Technical Leader

The technical leader is the biggest advantage of this methodology compared to traditional SCRUM, since he must program alongside the developers if necessary. He must also have a good knowledge of the technologies worked on to support developers. He is responsible for performing the analysis and estimations in the refinement.
He must also teach the methodology to the team members. 

DEVOPS

The devops team must ensure the following: 

• Have a development environment where developers can upload whatever they need, without continuous integration.
• Have a QA environment where the testing team can upload the versions created without continuous integration. 

Additionally, you must coordinate with the technical leader the way to move up to pre-production.

QA 

The quality team in FLEXIN Scrum must participate once the Sprint is over, verifying the delivered functionalities and if any are not correct, generate a bug in the new Sprint.

Here the ideal is for the QA team to have its own QA environment to which finished versions can be uploaded and thus carry out the tests they require without interrupting anyone.