The 'Secret Sauce' In your recipe for successful cross-team capacity planning
Hi Pgm Community!
If like me you have always wanted to demystify the scary world of Cross-Team Capacity planning and figure out a simple yet effective way of breaking down complex large pieces of work in to smaller more manageable chunks and track across multiple teams then this post is for you!
Full Disclosure! Whilst this Post shows you how it is possible to do Cross-Team Capacity Planning this is not a complete DIY Manual for setting up all aspects of this approach. I will link out to Atlassian University modules or helpful links where possible to show you how to achieve some of these steps!
What is ‘Cross-Team Capacity Planning?’
Put simply the clue is in the name. It is the ability to drive insight into the Capacity load and limit for a group of teams across a shared backlog.
Who Can Do It?
All Teams! I find often the myth persists that only Delivery or ‘Dev’ teams have the ability to forecast and plan work, however this is not true. Operations teams, Business Teams - heck even Finance and Legal teams all have the ability to capacity plan. As long as there is an identifiable Backlog of work that can be estimated and sized - you can capacity plan.
Operational and Process Setup
As we know in the world of Cross-Team planning not all Teams and processes are created equal. However the best chance for success here is predicated on agreeing on a few sets of homogenous fields and processes - namely, the following;
Agree on your Team Structure - ‘Who’s doing the work?' (Mandatory)
-
Seems simple but make sure you understand and allocate a clear Team Structure for who will complete the work
Agree on your Capacity Currency/Metric - ‘How are you estimating/measuring your work?’ (Mandatory)
-
It is important that you all agree on a single currency for Planning. This is for a few reasons;
-
So you all speak the same language when it comes to estimating and planning and not conflating Story points for example with another teams Days and Weeks estimates
-
So the Tooling and reporting can work harmoniously. Some of the tools (as you will see) will not play nicely with differing levels of effort metrics.
-
T shirt Size Currency/Metric Conversion per team - ‘How can you size large pieces of work before you break them down?’ (Optional but strongly recommended)
-
T Shirt sizes form the basis of your high level effort estimates. They allow Teams to roughly size and plan before breaking large buckets of work Into smaller manageable pieces.
-
The T-Shirt sizes (although rough and prone to more error than smaller sized estimates) can be converted in to an effort metric. I.e. If we are using Points, a Large could be lets say 200 points, a Medium 100 and so on. These estimates can be refactored as you learn the true nature of what your original T-Shirt estimates end up being once delivered.
Agree on a unified ticket Architecture - ‘How are you all defining and tracking your work?’ (Optional but strongly recommended)
-
Having a ticket work Architecture allows all teams to agree on how to split up work items. i.e. You could have Epics as your largest pieces of work and Story’s as your smallest. Defining what these work items are and how they are used, estimated, allocated and tracked will make the whole process run a lot smoother!
-
See below for how you can break down a problem for a Team into its constituent parts
-
Tooling Setup
Field Alignment (Mandatory)
-
As mentioned above, once all teams define an agreed effort metric you need to make sure this is implemented as a field in all of your Issue Types in Jira.
-
Other useful and important fields such as Team, Component, Sprint, Release (Fix Version) will all be native fields that should appear naturally in your tickets.
Boards/Sprint Backlogs (Mandatory)
-
In order to understand what is being done and when by we need to use Scrum Boards which have Sprints. This is so we can do the following;
-
Understand what is being done by which Team
-
Understand how much can be done over a certain time period per Team
-
Give a general time box period of when something will be done per Team
-
Create Teams and Capacity Limits
-
Teams is a generally new piece of Functionality in Jira and is now shared across Atlas too! Teams can help you understand work that is assigned to a group of people at the Strategic and Execution levels
Same Sprint Sizes and Start/End Dates (Optional)
-
Ideally all teams should have similar Sprint Cadences - this just makes things easier to understand. For example when i say it will be done in Sprint 7 everyone understands what Sprint 7 is.
Automation (Optional but strongly advised) - Automation Course here
-
As anyone who uses any planning tool will know - bad data in means bad data out. The whole point of us going to such lengths to do Cross-Team planning and getting it right is to gain valuable insights into what we are doing and make more informed decisions - thus saving time. Therefore getting the data entered in correctly in everything from the Team field to the estimation field is the lifeblood of how this Operation works.
-
Using Automation can be super effective at reducing the time taken to enter data into tickets that can be inherited or inferred from parent or linked tickets. For example as mentioned above we convert our T Shirt sizes in to an effort metric (we use Story Points) via Automation. Then once we start actually breaking down that large piece of work into smaller deliverables with better estimates Automation runs again to back out and remove the original estimate and instead infer a roll-up of its constituent parts. If you’d like us to show you more on this please comment on this Post!
Combining it all together (The Secret Sauce)
Advanced Roadmaps
What is Advanced Roadmaps? - Advanced Roadmaps (Plans)
Advanced roadmaps is a tool primarily built to help track and manage work at scale for teams or teams of teams. The tool does this by ingesting tickets from any board, project or filter to showcase the work you care about all in one place.
The reason why this is the Secret (or not so secret as it comes with Cloud Premium) sauce in your toolkit is that there is no other convenient way for you to see all of your teams operate and see their capacity loads in one place (unless you have Analytics - which we come on to at the end of this post).
Why and how do we use it?
Team Capacity
-
Set your Team capacity against your teams in the Team module. From here you can assign a Team to a board where it will read Sprints from that board to assign to your team
Forecasting
-
Once you have Teams with capacity and work assigned to those teams by using the ‘Team’ field and then assign dates or Sprints to that work then AR will do the rest and begin to show your Sprints filling up like magic!
-
AR will even forecast Sprints when Sprints are not available in your backlog. To do this again simply ensure a Team value is applied and that the work items have dates.
-
Changing Sprint Capacity
-
Holiday period coming up? A team mate on Vacation? Worry not as you can also change future sprint capacity loads on the fly to reflect this
-
-
Modelling
-
The great thing about AR is you can chop and change and move things around to your hearts content to work out the best cross-team schedule and plan for you. These changes can then be saved into Jira or discarded at any point if you change your mind.
-
-
Milestones (Releases)
-
AR also allows you to use ‘Fix Versions’ as Milestones. Use this to understand how on or off track. you are for a specific goal or time period
-
-
Dependency tracking
-
An In-built Dependency tracker will help you identify Bottle-necks and also highlight the critical path. This can be done for all teams or a subset of teams over any duration of time.
-
Taking it to the next level!
If Advanced Roadmaps is the secret sauce then Atlassian Analytics is your taste testing kitchen. It lets you know how everything is going on. How well you’re estimating work, how well you forecast, which teams are working on what, what’s the relative size of your pieces of work in relation to one another? To learn more on this stay tuned for a post coming the week of January 23rd 2024 to learn more!
Was this helpful?
Thanks!
Alex Frost
10 comments