Building Agile Teams and Handling the First Iterations
In software development, we often find ourselves struggling with estimations and ever-changing scenarios. This causes delays in delivery or an increase in the overall cost. Fortunately, there are many best practices we can implement to help mitigate these problems. In this post, I will outline ways I have learned to avoid delays in early iterations of development when building Agile teams.
Estimating is Tricky
In Agile development, estimation is key. Not only is good estimation necessary for effective Sprint Planning, but it’s also necessary in order to reap the benefits of Agile development. When you are able to accurately estimate your team’s efficiency, you can better communicate with stakeholders, managers, and other teams so that the organization as a whole is more efficient, and expectations are clear. If you are starting to use Scrum with a brand new team, estimating the initial user stories and planning the first Sprint can be quite challenging.
When initially building Agile teams, you won’t have any criteria with which to determine whether the team is overcommitted or not. In Sprint One, you will lack any previous velocity data to at least forecast the team’s performance. Additionally, the team might be unfamiliar with factors like the business rules, technology stack, or any non-functional requirement within the project that can directly affect the first estimations.
Before examining how to address this, it could be helpful to understand which kinds of cognitive biases can affect those first estimations in a Scrum team. Whether it is during Backlog Refinement or Sprint Planning, consider the following biases throughout the estimation process; this will help to understand and continuously improve the team’s criteria for estimating.
The Planning Fallacy
This is a very common phenomenon caused by an optimism bias within a team. It is a tendency to underestimate the time/effort needed to complete a future task and occurs regardless of any past knowledge of similar tasks. The team tends to concentrate on the most optimistic scenario for the task rather than using any previous experience to make a more realistic estimation. This provokes inaccurate estimations that likely translate into delays.
Wishful Thinking
Similar to the optimism bias, the team may also think that tasks will be finished quickly and easily because that is what they want to be the case. The tasks are evaluated based on a desire, which leads to their underestimation.
Temporal Framing & Thinking
When an Agile team is urged to think in terms of dates, both long and short term, their predictions can be heavily influenced. When a deadline is perceived as rapidly approaching (e.g. a Sprint), the team might tend to attach a conservative factor to their estimates. The opposite scenario is when a date is perceived as being far away (e.g. a release planning), which drives the team to feel over-optimistic about a forecast.
Building Agile Teams and the First Iterations
Once the backlog is estimated (or at least a good part of it), here are some tools that could help to lay out the work for the first iteration:
Focus on Team Capacity Instead of Team Velocity
Velocity can be an intimidating term, especially for Agile teams that are just ramping up. As a Scrum Master, you might find yourself or the team struggling with concerns like:
• How much can this new team accomplish in the first Sprint?
• On what criteria should we base our initial story point estimates?
If you want to calculate your team’s velocity in Sprint One, you must remember this: you can’t. At least not accurately. Velocity is just the sum of the estimates of the user stories completed at the end of a Sprint. So, when first building Agile teams, there is no previous data or evidence on how much the team can accomplish within an iteration.
Before jumping into establishing a team velocity, let’s focus on what is important to settle during the first iteration: establishing an agreed commitment with the team and starting to generate performance data for future usage.
Capacity Planning
Let’s say the team is holding its first Sprint Planning session, and it’s time to decide which items are going to be pulled in for the first Sprint. Some or all of the user stories in the backlog have been previously estimated.
Considering a 2-week Sprint (10 days), let’s suppose we have a team of 5 members.
Since one hour is the basic effort unit of a person, this example will be based on hours. The first thing we need to know is the total hour amount for each person and the team.
Let’s suppose that 1 day is composed of 8 hours of work, which results in a total of 80 hours per person during the Sprint and a total of 400 hours for the whole team. The initial capacity would look like this:
| Team Members | Available Hours |
|---|---|
| Team Member 1 | 80 |
| Team Member 2 | 80 |
| Team Member 3 | 80 |
| Team Member 4 | 80 |
| Team Member 5 | 80 |
| Total | 400 |
However, estimating 8 hours of work entirely dedicated to a project every day is not realistic. There are Scrum ceremonies, ad hoc meetings, and other arbitrary events that may reduce the time a person is fully focused on a task. So here is a way to come up with a more realistic number of hours per day for each person:
When building Agile teams, the first Sprints may be challenging in terms of productivity. A good place to start is by halving the total number of theoretically available work hours per person and then increasing it as the team evolves and becomes more mature.
As an example, instead of estimating 8 hours per person, use 4 hours. This may seem low, but in the first stages of a team, it can be helpful to start low and gradually increase this total. Applying this rationale, the team’s capacity might look similar to this:
| Team Members | Available Hours |
|---|---|
| Team Member 1 | 40 |
| Team Member 2 | 40 |
| Team Member 3 | 40 |
| Team Member 4 | 40 |
| Team Member 5 | 40 |
| Total | 200 |
With this method, our total number of hours per person each Sprint is 40, with 200 hours for the entire team. Since no previous velocity has been logged, this is a better approach than trying to come up with a focus factor.
The next step would be to ask the team members if anyone will have days off or less availability. If someone, for example, has 2 days of paid time off, then 8 hours would be discounted from their availability, as shown in the following table:
| Team Members | Available Hours |
|---|---|
| Team Member 1 | 40 |
| Team Member 2 | 40 |
| Team Member 3 | 32 |
| Team Member 4 | 40 |
| Team Member 5 | 40 |
| Total | 192 |
Once the team has defined their availability and the total number of real hours, it’s time to decide what is going to be included in the Sprint. One useful technique to make that decision is the Weighted Shortest Job First (WSJF) prioritization model. After settling on a set of user stories that they and the Product Owner feel comfortable with, the members of the team discuss the stories and come up with individual tasks for each one of them. All of those tasks are assigned to someone on the team, and everyone estimates the tasks with hours considering all perspectives and criteria.
After the sub-tasking process, there will be a total number of hours assigned to each member and the whole team. These numbers will help to determine if a team member is overcommitted or not. Moreover, if the total number of hours coming from the tasks exceeds the total hours available to the team, then the team must decide if one or more user stories should be pulled out of the Sprint commitment.
The next table shows, for example, one team member who is overcommitted and another team member whose assigned work is below 50% of its capacity. These results are perfect topics of debate during the Sprint Planning.
| Team Members | Available Hours | Hours Assigned | Commitment |
|---|---|---|---|
| Team Member 1 | 40 | 38 | 95.00% |
| Team Member 2 | 40 | 30 | 75.00% |
| Team Member 3 | 32 | 42 | 131.25% |
| Team Member 4 | 40 | 12 | 30.00% |
| Team Member 5 | 40 | 37 | 92.50% |
| Total | 192 | 159 | 82.81% |
The real outcome of this whole process is the implementation of specific practices and better conversations when it comes to estimating and planning the first iterations when first building Agile teams. All these numbers should be used to make thoughtful decisions. It is important to keep in mind at all times that, in an Agile environment, teams must embrace change because it always occurs. However, the more data and tools you use, the more accurate your planning process will be.
Conclusion
Even though the first stages of a project can be loaded with uncertainty, there are ways to reduce the risk of not knowing the team’s behavior and performance. As a Scrum Master/Product Owner, it is important to understand all the biases that can affect the estimations when first building Agile teams. Knowing them will help to refine the team criteria. However, it is important to keep in mind that, at the end of the day, story points and hours are just an estimation. The most valuable asset of those first grooming and planning sessions is the habit of having the right conversations. Capacity planning is a valuable approach for preparing the first iterations of a team. However, it is not very practical for forecasting the delivery. So using story points right from the beginning can support the inspection of the team’s performance in the future. Teams could gradually start analyzing their velocity at the end of each Sprint. Such analysis can provide metrics like Completion Against Commitment (CAC) and average velocity to help make more accurate estimations in the future. Predicting a team’s performance is one of the benefits of using Scrum. Nevertheless, it’s not the ultimate goal. The Scrum framework focuses on producing valuable, potentially-shippable features constantly.
