International teams often work different days and hours. Israel makes an obvious example with the Sunday through Thursday working week. Norwegian employees work 7.5 hours per day, while there is the 9-hour working day in Singapore. How to plan dispersed or distributed teams in Jira?
Distributed vs. dispersed team
The terms are sometimes confused. Historically, and in real life, we more often deal with distributed teams: one team in San Francisco, another team in New York, yet another one in Paris. All people in a single team work in the same geographical location.
Example: A global advertising agency with distributed teams catering to their local country markets. Each team consists of a brand strategist, a copywriter, a key account and a social-media marketing specialist.
With a dispersed team, on the other hand, you manage professionals dispersed throughout a country or the world, but grouped into one team.
Example: an Android/iOS apps software house, that has a programmer in Poland, two programmers in UK, testing staff in Mexico, and a salesperson in Seattle, U.S.A.
How to plan capacity of a distributed or dispersed team in Jira?
As Jira doesn’t recognize the concept of “team”, most project managers use some plugin, or app for resource management. Regardless of which plugin you choose, there seems to be a consent on how to plan a distributed/dispersed team’s capacity:
- Create multiple workload plans, to cover all the “cases” in your organization. Typically you’ll want to set up a “general” workload plan, i.e. Mon-Fri 9 to 5 and some specific ones, e. g. a “Israeli workload plan” – Sunday through Thursday 9 to 5 and Friday 9 to 12 and a “French workload plan”, i.e. Mon-Fri 8-12 and 14-18.
- Assign a workload plan to each team member.
- Next step is to build teams that are made of individual people. Now, assign these teams to programs.
- Now you should see capacity of each team on Resource Grid in Team-centric mode – we are talking about BigPicture project management plugin for Jira here.
Capacity of a team vs. capacity of an individual
A capacity of a team tends to be perceived as the sum of capacities of the team’s members. Quite similarly, the sum of working days of the members make the team’s working days.
Example: Josh uses the “general” workload plan, Mon-Fri, 9 to 5. Ann uses the “Young mum” workload plan – Fri-Sat 10am to 2 pm. The team of Josh and Ann (both members with 100% availability) will have the following capacity:
- Monday 8 hours
- Tuesday 8h
- Wednesday 8h
- Thursday 8h
- Friday 12h
- Saturday 4h
- Sunday 0h
- Weekly capacity of the team: 48 hours
Some teams use “fixed” weekly capacity, regardless of how much they actually work – more on that here.
Have you noticed the “both members with 100% availability” statement above?
Typically a team member devotes 100 per cent of his efforts to a single team. But consider this example: Jacob is a programmer and an avid tester. He shares his duties between two teams. Therefore his availability could be as follows:
- 50% in the Agile programming team,
- and 50% in the Testing team.
Although Jacob’s daily capacity is 8 hours, because of his 50 per cent availability in the programming team, he brings only 4-hour capacity to that team.
How to deal with time zones?
Most Jira resource/PPM apps have no “timezone” field, but is this an issue? Some project managers tell us that they plan capacities of their international teams in the project managers’ time zones, no matter in what country their staff members actually work.
Example: if a project manager is based in New York, Eastern Time, UTC -5:00, and they have a team member in UK, Greenwich Mean Time, UTC +0, and that team member normally works 9 am to 5 pm, then the project manager could set up the following “UK workload plan”: Mon-Fri, 4 a.m. – 12 noon.
How to choose a plugin for resource planning in Jira?
If you’re not sure, just pick a well-balanced complete PPM plugin with a resource module. Such an app would consist of several modules, e.g. resources, as well as risks, Gantt chart and roadmaps. Most mature resource-related apps for Jira show some bias, in other words they focus on (an) aspect(s) of resource management. There is an article discussing differences between major resource management apps for Jira.
We recommend our native BigPicture. The video shows how to plan capacity for an international team in BigPicture/Jira.
How to deal with daylight saving time?
Since some countries observe daylight saving time, is it advisable to have two separate workload plans: for winter and for summertime? In most cases the answer is “No”, as long as project managers are capable of doing their own computing. 8 hours per day, or 7.5 hours per day, or whatever the number of hours, is what really matters with resource planning.
While the majority of the Western world works Monday through Friday, 9 am to 5 pm, or 40 hours per week, there are notable exceptions. Find some of them in the table:
|Country||Working week, typically||Hours/week, typically|
|Brazil||Mon-Fri, 8h/day, Sat, 4h/day||44|
|Hong-Kong||Mon-Fri or Mon-Sat, 8h/day||40-48|
|Israel||Sun-Thu or Sun-Fri, 8-8.6h/day||40-42|
|Singapore||Mon-Fri, 9h/day or Mon-Sat 8h/day||up to 44|
|South Africa||Mon-Fri, 9h/day||45|
|UAE, United Arab Emirates||Sunday–Thursday, 8-9h/day, less 2 hours in Ramadan1
1Ramadan lasts 30 days is a floating “holiday” (January-December depending on year)
|40-45 (30 during Ramadan)|
Firstly, what is the true cost of PPM software implementation? Traditional vs. hidden costs. How to reduce the latter? Read more
Secondly, is Gantt chart an agile tool? Check three applications of modern Gantt charts in agile management.
Thridly, deciding between BigPicture and BigPicture Enterprise? Check 6 signs your organization should upgrade to BigPicture Enterprise.
Dispersed and distributed teams capacity planning boils down to setting up separate workload and holiday plans for each country in your Jira resource app.
Although not about capacity planning per se, consider these two things:
- E-mails, on-line conferences and all the communication in dispersed teams tend to be delayed compared to co-located teams.
- Dispersed teams tend to be less agile, as daily stand-up meetings are impractical with remote team members.