The development of Software applications is an extremely complex job that requires professionals with a high level of knowledge, talent, intellectual capacity and, also, a vocation to face the need for continuous updating.
It may be that I am not impartial since I am a programmer, but I do not know of any profession that needs constant recycling and learning at the level of “code picking”. Especially because we are in a frenzy of news that takes the saying “shrimp that sleeps is carried by the current” to its most cruel reality.
To increase complexity, It is a work that is carried out in a team, and with communication and organization problems inherent to the limitations of natural language.. We have all had the experience that a requirement, a functionality, described in detail in a document in both the what and the how, suddenly turns around and where it described doing one thing, we found that it could be interpreted in another way. very different. And the greater the effort required to complete the requirement, the more doubts and misunderstandings emerged.
Definition of Sprint Backlog
A few weeks ago I wrote an article on Product Stacks, and today I want to talk about the Sprint Backlog, or Sprint Backlog. Which is, in my experience, a powerful tool for organizing the chaos a team faces at every iteration.
The Sprint Backlog is a list of tasks that comes from the breakdown of User Stories that make up the Product Backlog (Product Backlog). Understanding as task, divisions of work that can be carried out in a maximum period of two days and a minimum of one hour; that they are atomic in the sense that they can be finalized without the need for them to be dependent on others; that they are assigned so that the team can easily know who or who are doing them; and that they are estimated to be able to know how many we can add to the sprint or to calculate the team’s speed.
But an image is worth a thousand words and below I show a tab of a Task in the tool that I normally use, and that is similar in all the tools that you have at your disposal in the market. In this case, Tema foundation Server Preview, a Beta version of the ALM from Microsoft, but in the Cloud.
The construction of the Sprint Backlog is, in my opinion, the most important meeting of the Scrum methodology after the Retrospective. Is the moment where the team takes responsibility for its work and makes decisions based on the truth that no one knows as much about development as developers. This, which seems obvious, has been one of the great dysfunctions of the formal methodologies based on architects and functional analysts who, by means of load sheets, sent the work to the programmers, hoping that they would not think, only that they would chop code. Which has been shown at the cost of a lot of money and overtime, which is an approach with a huge risk of failure.
The meeting in which the Sprint Stack is built is the Planning Meeting, or Planning Meeting. The entire team is analyzing both functionally and technically, each of the user stories according to their priority, to break them down into estimated tasks. Hidden functional requirements often emerge at these meetings or technical decisions are made on how construction is to be approached.
Depending on the speed of the team, you can make a close forecast of how much work it is capable of developing in a Sprint, for which tasks are added until “fill the bowl“. And so all the members of the Team can take responsibility for the work to be carried out safely and with guarantees, since the decision of how, how much and why is taken by the person who is going to do it and does not come from the stars by the invention of someone who is not going to stain his hands.
At the end of the Planning Meeting, we will obtain a new Scrum board where the prioritized user stories will be displayed, and all the tasks with which we are going to build them and that enter the Sprint Timebox.
Day to day
The ultimate goal of a Sprint Backlog is be the source of tasks that we are going to move on our board, be it physical or electronic as in this case. The reason for a board where we represent our workflow is beyond the scope of this article, but I can tell you that it is a very powerful tool so that the team and the actors involved in the project can have an overview of the project. current status of the project.
One of the liturgies that make up the Scrum framework is the Daily Meeting. Where each of the team members shares with the rest the tasks in which they are working, the path they intend to continue on and the impediments that prevent them from moving forward. In the most “mature“The movement of the task cards is carried out throughout the day, in real time so to speak. Instead in the first steps of the teams in agile methodologies, I prefer to update the dashboard during this short daily meeting to reinforce communication, the feeling that the dashboard is really useful and for the team itself to keep track of the status of the Sprint.
Also, and following the concept that the team is the one who knows the most about development, which is why it is the one who makes the decisions about the construction, here tasks can be added or removed from the sprint. Either because when the design emerges, it is verified that there are more tasks to be carried out, because the speed of the team is higher than expected and more tasks can be added, or because impediments of any kind force us to pass tasks to the next sprint. or discard them.
A Sprint Backlog is the list of tasks in which you subdivide the user stories that describe the functionalities that make up a project. This list is defined and estimated at the Sprint Planning meeting at the beginning of the iteration. Tasks must be small and loosely coupled in order to estimate them. As many tasks are added as the speed of the team.
Who decides what tasks, when, in what order and in what way to build them is the team. It is their power to be the one who has the necessary knowledge to make decisions about the construction of the project.
It is a powerful organization tool since it avoids jumping into code without having the minimum planning (ASM), gives visibility to the team of the work to be carried out and allows maintaining a dashboard where the work flow and the status of the project are visually observed.