One of the challenges in the use of Scrum is to predict how much of functionality a team is able to deliver each sprint. Many try, in a vague attempt to create a metric, to assign a story point a certain amount of work to be delivered, rather than looking how a team play their roles and perform their deliveries. For example, a story point is equivalent to a CRUD with 8 fields that accesses a table in the database. This approach does not work, because a team is made up of people with different experiences, perceptions and problems (personal or professional). Individually and collectively, a team always has different emotional and technical characteristics from other teams. Team members never take the same time that members of Team B took to adapt to each other. Teams will never manage exactly the same conflict situations or have the same productivity. Finally, in sets filled by human beings, there may even be a statistical standard for productivity, but never an industry standard, accurate and predictable. There will always be a margin of error. Then comes a question for reflection: is it better to draft a plan and make your team follow this plan at any cost, in favor of a contract or corporate goal? Or would it be better to identify a target and track the performance and growth of your team, guiding it toward its mission, enjoying a harmonious, happy and highly productive environment, and make necessary adjustments to the project plan for the sake of your customers’ satisfaction, offering them transparency, with no surprises?
Scrum Teams are empirical, as well as babies
Scrum is an empirical process, and its teams will also have the same behavior. Scrum teams experience and adapt to various obstacles during a software project. They are not afraid or ashamed to make mistakes because they know that these errors will add more value to the customer's business. In The Artful Making: What Managers Need To Know About How Artists Work, Robert Austin provides us the example of an empirical dance company. To achieve its goal, the team tests the coreography that has been created, records it, and observes the result from different angles, until it achieves the desired excellence level. Likewise does a Scrum team: inspecting and adapting. Observing all aspects of their actions and practices and their consequences. There is no patterns or practices before the beginning of the project. There is one goal and one deadline, and the team organizes itself alone, with the guidance of the ScrumMaster to achieve them. Practices and patterns, behavioral or technical, emerge during the development of software, and, of course, work very well - almost exclusively - for that group of people. That is, just as babies learn wandering, - and they fail as much as necessary to complete the learning experience - a Scrum team learns the same way. However, with the advantage of already owning their logical reasoning formed.
Nevertheless, one must at some point in the project (preferably as soon as possible) to know the potential for delivery owned by a team, per sprint, or its velocity. Therefore, it is essential to the initiation of a project, focus on training / coaching the team and getting its average velocity. While the team is already developing the software from the business requirements, it begins to know itself and to self-organize, gaining a working standard. Without this mindset, it is impossible to know the pace of a team. The delivery capacity will always be "what the team can deliver during this sprint."
A team does not move like a car. A team beats like a heart.
One of the premises of a Scrum team is that it has a sustainable pace. It works at a pace within which he can maintain the quality and completeness of their work without endangering their health and wellbeing. As well as our hearts. A Scrum team beats just like our heart beats. For us to be healthy, our heart beats at a steady pace, different for every person, but within an expected standard. Within a range. This rithym should be felt early in the project, when the focus is on detecting the productivity of the team. At the beginning of a project, a team must be “examined” by its ScrumMaster, which will help the team draw and keep its own pace through the removal of impediments in their work and protecting them against external influences. A team will always have a range of production, its maximum and minimum of effort over the duration of the project. Its average will be used to maintain its sustainable pace. And any change in the composition of the team affect its heartbeat, either in the productivity realm, or in the psychological realm. The workflow of a Scrum team can be as predictable as the blood flow. But human beings are made up of emotions, which cause variations in this flow. If a team is composed of various human beings, it’s a fact emotions also affect its workflow.
Anxiety: the evil of the century
Managing a software project is basically to manage knowledge acquirement. Business knowledge about what are the requirements of the software, and technical knowledge about how the goal will be reached. Throughout the project, one emotion is always there: anxiety. We are rushed by the expectations generated by changes in requirements, we look forward to the proximity of the deadline, we are anxious for the team's performance, we are anxious for the departure of a team member. Finally, a software project is stressful. There is no heart that can stay alive. And if the heart of a software project is its development team, it should be observed closely and carefully. And this is only possible by knowing the heartbeat of the team per sprint. Its average capacity of delivery. Hence, one should be aware of what the team has to say about its work under the following circumstances:
Low blood pressure: If a team reaches a beating below its minimum, will inevitably be affected by the anxiety of managers, sponsors and users. A delivery was scheduled and was below expectations. The team has something to declare. Teams do not perform badly simply because they want to perform badly. Something is in their way, either emotionally, or professionally. And besides anxiety outside, the team builds its own anxiety. Because they know they are performing under the expected, and because they are suffering for some fact.
High blood pressure: If a team starts to engage with sprints above its historical maximum, probably it is under pressure to do so. Anxiety grows because the team knows the delivery expectation is above their maximum, and it probably don’t even know if it can deliver what it promised to deliver. Its effort to make this delivery will be higher than normal, breaking into the welfare of the team. Probably overtime will be used to achieve the goal, and a new velocity record will be set up for the team if it can deliver in subhuman conditions. The team will reach that velocity for two or three sprints more, and than stress caused by high levels of anxiety and fatigue will appear in silly flaws and internal conflicts.
In both cases, the anxiety to meet or exceed expectations leads to stress and even frustration. It is so important for the ScrumMaster to watch and assist the team in maintaining its sustainable pace. This rhythm is certainly much more productive and creative than "the maximum that can it handle."
Overtime: the adrenaline rush of a team
Like adrenaline, overtime should be used with caution during a project and a planned way. If a person is subject to frequent discharges of adrenaline, his/her heart will probably accelerate to a stop. It gets tired. If a team is subject to overtime for an abnormally long time, probably it will accelerate to stop. It gets tired. Its members will be discouraged, frustrated, produce less than normal at a given moment of intense journey and, ultimately, will leave the team on behalf of their health or life quality. Overtime should be used as adrenaline, with a definite objective and for a definite period of time.
Success? Maintain a healthy pace
Without any doubt, the heart of a project is the team that supports it. There can be a willingness to start a project, sponsors to start a project, a leader to guide its implementation. But all of this is useless without a team to transform the objective into reality. It is not enough just to have a team that makes the objective reality. This group must be sufficiently motivated, united and comfortable for the objective to be achieved with quality. Thus, a team need to be able to maintain a sustainable, healthy pace. A team rhythm that provides unbelievable deliveries, even for its members.
One of the biggest mistakes that some managers make is to assume that a sustainable pace is not enough. However, if a sustainable pace is not enough, is unsustainable? Of course not. Enough is keeping a pace in which the team can make its deliveries consistently, correctly, with quality, leading to predictability, so highly prized by managers and well-being for its own members. Like a healthy heart.