For many teams becoming agile is a journey, not a point-in-time transition. While many teams share similarities, each team is unique in its skills and relationships. In this article, I’d like to focus on teams that have different, specialized skill sets; teams that can benefit from capacity planning, which ensures that there is the right amount of work for each person in the iteration. Many of the concepts in this article are for organizations that push work to the team. As teams transition to agile, learning where and how the team spends time is important. They can then better educate the business on moving to a more agile pull model. We will start with optimizing your team, estimating and scheduling work, and learning how to make continuous improvement a part of the team culture.
Your team: Generalists or specialists?
When managers build teams they usually focus on teams with generalists, specialists or a mixture of both. Let’s start with a few key definitions:
- Generalist (n) – A person with a wide array of knowledge that can work on a number of interdisciplinary tasks.
- Specialist (n) – A person who has unique knowledge on the team relating to a particular job, area of study, etc.
Many agile concepts focus on teams composed of generalists. For instance, scrum focuses on the team commitment and rebalancing work to meet that commitment. If everyone has the same skill sets, the team can easily rebalance work to meet the sprint commitment. What happens to teams that can’t rebalance work? Capacity planning can help any team, but teams with specialists will benefit most. Capacity planning is ensuring that everyone on the team, particularly the specialists, have enough work for the entire iteration.
Estimation: Using science and art
All of capacity planning hinges on good estimation practices, since inaccurate estimates make scheduling almost impossible. Many teams estimate in days or hours when beginning the agile journey. Breaking user stories down into component tasks that last no more than 8 to 12 hours is a huge step forward in taming uncertainty. My focus here is to show how JIRA can help the team understand with time management and planning. Let’s look at a sample software engineering team with designers, different kinds of developers, test engineers, and engineering services. We want to ensure that everyone has enough to do for the whole iteration.
I’d focus on looking at the team as a collection of skill sets. When estimating in hours, I recommend no one take on more than 65 hours of work in a two-week sprint to allow for the cost of doing business. What’s the cost of doing business?
We all have email to follow up on, meetings to attend, and other recurring tasks. Filing tickets for this type of work is too much overhead, so I only plan 75 percent of any given iteration with task work. If we have more than one person with similar skills we manage capacity by skill set rather than person.
Execution: Making every hour count
You can’t improve your processes if you don’t measure them. To help teams keep track of time, JIRA supports a feature called time tracking, which allows teams to estimate work and log the amount of time spent on an issue into JIRA. JIRA then aggregates that data in several useful reports. JIRA has a panel in the issue detail view that exposes time information.
JIRA has a number of time tracking options. After working with a number of teams, I’ve included the ones I recommend most. Use hours as the default unit of measure as it makes the math easier working inside of smaller iterations.
Moving forward: Aggregating the work ahead
Now that the team has estimates on all their issues, the workload pie chart makes it easy to see how much work is on a particular person’s plate. The workload pie chart queries the estimate in each issue and puts the total in an easy-to-read chart. I’ve set up a dashboard showing the original iteration commitment and how it might look after a few days of work. Here we see that the team changed the estimates to reflect new information after working for a few days.
In this chart on the left, Max, a server engineer is just about at capacity for this iteration, while Jennifer, another server engineer, has some spare capacity. Since they have similar skill sets, we can easily reassign some work from Max to Jennifer. The chart on the left will remain static throughout the iteration so the team can see the original projection. As we learn more about the work in the iteration, we can rebalance the chart on the right as needed. Keeping a close eye on how work progresses gives the team and the project manager the ability to remain proactive.
We can also abstract how we assign out work. By using a custom field called team, we can tag all of the user stories that require server skills, web development skills, and the test skills. If we leave each of the stories unassigned until someone takes action, we can plan work more flexibly.
If we have five server engineers, we know the amount of work we can take in a particular sprint for that discipline cannot exceed 300 hours. In this case, rank becomes critically important. As team members complete tasks, they will take off the next most important task in the current iteration. That way, the team is always working on the highest value items. By combining individual silos into a larger set of work, we can deliver back to the customer more efficiently. JIRA Agile’s agile boards can help keep the most important items in focus using ranking.
The workload pie chart can display work using a number of fields. Project managers can see work outstanding for a sprint, version, by client to just name a few.
Retrospectives: Make growing a priority
The retrospective is one of the most important pieces in agile methodology and team development at large. Retrospectives are where the team gets to learn and then ultimately grow. The time tracking report provides valuable information back to the team. The team can easily compare estimates with the actual time spent to improve the way they estimate work. Let’s take a look at an example:
The time tracking helps the team understand how work got done, and it gives everyone measurable results from the iteration that can then drive planning for the next iteration. For tasks where the estimate is very different than the actual, ask yourself a few important questions:
- Could I have broken this task down into smaller increments?
- What would have been most helpful to know in the beginning?
- Would there have been a way to parallelize the work?
Ready to learn more? Try a free OnDemand trial of JIRA today!