Before landing into calculating agile effort, let’s briefly summarize what Sprint Planning means.
In Scrum, before starting a new Sprint, the Scrum Master always calls a meeting with the entire team to plan the work to be done which is called Sprint Planning Meeting.
In the Sprint Planning Meeting, the main objective is to prepare and share what exactly is going to be done in the next Sprint. From this meeting the team should leave a very clear idea of what is going to happen in the next two weeks (or the duration of the Sprint) and how we are going to achieve it.
Stages of the Meeting
First stage. Strategic: We define ‘What’. (Review). It is done in a timebox of about two hours (if the iteration is two weeks):
- The product owner presents to the team a prioritized list of the requirements from the Product Backlog or project, sets the goals of the iteration (so that it helps to take decisions during its execution) and proposes the most priority requirements to be developed in it.
- The team examines the list, asks the customer the doubts that arise, adds more satisfaction conditions and selects the most priority objectives / requirements that are planned to complete in the iteration, so that they can be delivered if the client requests them.
Second stage. Tactic: we define ‘How‘ (Planning). It is done in a timebox of about two hours (if the iteration is two weeks).
- The team plans the iteration, develops the tactics that will allow them to achieve the best possible result with an minimum effort. This activity is carried out by the team since it is responsible for organizing their work and is the one who knows best how to do it.
- The team defines the necessary tasks to complete each objective / requirement, creating the list of tasks of the iteration (Sprint Backlog) based on the definition of fact.
- With the entire list of activities, the team calculates the necessary effort to perform each task. We will dedicate a section in this article to highlight some techniques for estimating agile effort.
- Team members self-assign tasks that they can perform, self-organize to work even in pairs (or larger groups) in order to share knowledge (creating a more resilient team) or to solve especially complex objectives together.
For a Sprint Planning session to be considered successful and the goal fulfilled, we must pay attention to some important keys.
Pre-work Details
We must have the necessary detail of the backlog elements to be able to progress in the meeting. If you do not have the details, we should analyze and describe these in the same planning session, which will necessarily require the presence of someone with functional knowledge (preferably the Product Owner).
Mark Development Milestones
The team should imagine how the Sprint is progressing and mark tentative dates in which they finished concrete development tasks, and leave them ready for the tests.
Mark Testing Milestones
In the same way development milestones are set, they must also mark milestones for testing. This practice is especially recommended if there is a testing team (QA). Mark testing milestones are essential to properly distribute the workload of both teams.
Detects Third-Party Dependencies
During Sprint Planning it is also very important to take a quick look at the elements of the backlog that are supposed to be performed in the next Sprint, or are being performed by other teams. The goal is to find those impediments and dependencies of people and equipment outside our team. If we are able to detect these situations in advance, the Scrum Master can begin to contact and resolve these situations before beginning the process of refinement or detailed analysis of these elements.
Get the Commitment
Finally, it is important that everyone who is present is comfortable with the commitment acquired, team members must be aware of the commitment, since full trust is placed in the team to let them work without interruption throughout the Sprint. An experienced development team will know what their speed is and what they can achieve in a Sprint, so they can keep the commitments in a sustained way during the successive Sprints, preserving the confidence that has been deposited.
Calculating the agile Effort.
Since the early 1990s, many writers and subject specialists have evaluated different methods to accurately establish (be assertive) the effort needed to complete an activity related to software development. We could say that this has a lot to do with the developer, his experience, his habits and his “muses”. However, when working as a team, the most important thing is to establish a common metric to be efficient and effective in each activity to be calculated.
Mike Cohn, in his book Agile Estimating and Planning (2005), presents a graph in which you can see the relation between accuracy and effort, in his example with a simple approach he describes how to better understand this relation.
Assuming you decide to estimate how many cookies you have eaten this last year, your answer could certainly not put any effort into the estimation. To answer, it will be necessary to make a random conjecture. Assigning this to the Figure, you would completely be on the left on the effort axis and your estimation is unlikely to be accurate. You could move to the right on the axis of the effort if you spend about half an hour researching averages for the consumption of cookies. This would improve your precision on pure conjecture. If you feel the need to be more accurate, you could call your friends and family, see your invoices from previous supermarkets, and so on. You could even keep a statistic for a day, or, even better, a month, and then extrapolate your observations to how many cookies you think you ate in a year.
Look carefully at the Figure and observe a couple of things. First, no matter how
much effort is invested, the estimation is never on the top of the accurate axis.
No matter how much effort you put into an estimation,then an estimation is still an estimation. Then, no amount of extra effort will make a perfect estimate. Next, note that with a little effort you can dramatically move the accuracy from the base. As shown in the Figure, approximately 10% of the effort gets 50% of the potential accuracy. Finally, note that eventually the accuracy of the estimate decreases if too much effort is applied.
At the beginning of every project, the development team is always making random guesses during the application. This is due to the uncertainty cone, which describes the evolution of uncertainty during the execution of a project. In the beginning there is little or no knowledge about the product and the result of the work, therefore the estimation is tied to great uncertainty. As we move forward in the project we get more knowledge about the environment, the business needs, the product and the project itself. This causes that the uncertainty tends to progressively reduce until disappearing, this happens generally towards the end of the project: an uncertainty of 0% is not reached until it has finished. This means that as a project advances, the teams tend to be more productive.
So how can we be more productive from the start? Is there a way to decrease guesses and be more precise in calculating the effort? The answer is yes; definitely.
Input – Process – Output
Every software process, no matter its size, can be observed from this perspective: Input-Process-Output. Considering this, then, we can establish a certain number of points to measure the complexity of the development, no matter which planning method your team uses, there will always be a joint measurement system that will increase the accuracy by maximizing its relationship with the effort.
Let’s analyze the inputs and outputs, they constitute the interface of our process, in this way we can have a complexity factor according to the type of interface. Gustav Karner in 1993 called this “weight of the actors”. There are three types of actors.
Actor | Description | Factor |
Simple | Another system that interacts with the system to be developed through a programming interface (API) | 1 |
Medium | Another system interacting through a protocol (eg TCP / IP) or a person interacting through a text mode interface . | 2 |
Complex | A person who interacts with the system through a graphical interface (GUI) | 3 |
For the calculation of the process there are other considerations, in object-oriented programming the effort measurement can be related to the number of classes (software entities) necessary to complete an element of development. It is important to emphasize that if the process in question is the product of a mathematical calculation and / or contains space time relationships, it must increase 1 or 2 points in the calculation of the preliminary factor.
In this way, the factor per process can be calculated as follows.
Process | Description | Factor |
Simple | 5 or less classes involved | 1 |
Medium | More than 5 and less than 10 classes involved | 2 |
Complex | More than 10 classes involved (consider dividing the task) | 3 |
Points of activity should fit into a Fibonacci series, 0, 1, 1, 2, 3, 5, 8, 13. This way it does not matter if you and your team use planning poker, t-shirt size, dot voting, or any other. Each member of the team will be more successful in calculating the effort required in each activity.
By practicing this technique in a short time, you and your team will be more accurate and precise in your effort calculation and could maintain your team velocity across the time.
