RELATED IDEAS
relative time-based estimates in capacity planning
Context:
One of the main activities when planning for capacity is rescheduling activities until each team's capacity is maximized but not exceeded . An activity (feature/epic/initiative) might be rescheduled multiple times in this process, until a compromise between business objectives, capacity and dependencies is reached.
Most features don't require constant effort in time. E.g. a big epic might require more PM/Design effort at the beginning, and more UI and QA effort at the end. The loading of each team changes in time.
Lastly, one might decide to increase a record's duration and spread the effort so as to decrease the team's loading throughout (teams work on features concurrently, and almost never sequentially)
The issue:
With the current implementation of capacity planning, each time we reschedule an epic we have to update every team's time-based estimate for that epic. E.g. if I move Epic A from an initial Jan 1 - Mar 31 timeline, to a Mar 1, May 31 timeline, I'll have to update every team's estimate correcspondingly. This is cumbersome and time consuming, and effectively offers no value compared to using a spreadsheet for capacity planning.
The Idea:
Allow users to define time-based estimates relative to the record's duration (linked to start/due date).
-
update the time-based estimate when the start/due date is changed
If the record is reschedule, shift loading in time
(nice to have) If the record duration is increased, spread the loading accordingly
( nice to have) If the record duration is decreased, compress the loading accordingly
Currently, for a given initiative A
Hours |
Jan 2020 |
Feb 2020 |
Mar 2020 |
Apr 2020 |
UI Design Team |
80 |
40 |
0 |
0 |
Frontend Devs |
0 |
20 |
80 |
80 |
It would be much better as:
Hours |
Month 1 |
Month 2 |
Month 3 |
Month 4 |
UI Design Team |
80 |
40 |
0 |
0 |
Frontend Devs |
0 |
20 |
80 |
80 |
-
-
-
-
-
-
- +1
© 2024 Aha! Labs Inc.•All rights reserved
Thank you so much for this generous overview! This is very helpful.
Hi Nathaniel,
That is true, but that feature does not work with time-based estimates. Let me explain with an example:
Let's take a fictitious Epic A. Epic A:
Currently runs from Jan 1, 2021 to March 31, 2021.
is currently estimated it as 80h, 40h, and 20h, for Jan, Feb and Mar 2021, respectively. This might be beacuse:
Aha's default behaviour is to bunch work required for non time-based estimates at the beginning of the epic (see https://big.ideas.aha.io/ideas/A-I-9455, and https://big.ideas.aha.io/ideas/A-I-8603), or
The epic has a varying effort for some teams, e.g. as a result of the design team being more involved in the early stages for feature discovery.
Having found I have no capacity in January, I now reschedule Epic A to run from Feb 1 to April 30, by either dragging it forward in my strategic roadmap, or by adjusting the Start and Due dates.
What happens:
Aha! automatically updates the estimate's duration to the new Feb-Apr timeframe, following the epic. However, this causes my 80hr estimate for January to be disregarded and a 0h estimate to be taken into account for February. My capacity report is now wrong, as (at least for the team in question) this epic should take 80h in Month 1, 40h in Month 2, and 20h in Month 3. The only way to fix this is to go into the estimate and manually update the monthly estimates to match the new date. But this negates the value added by Aha!
What I would expect
As I reschedule the epic to Feb-Apr, the estimate should update so that Feb=80h, Mar=40h, Apr=20h. This would maintain the epic "effort profile" but translate it in time, which is the correct behaviour (just because I reschedule an epic, it doesn't mean I can forget about that initial 80h in January!)
Happy to get on a call and chat about this and a few other features that I think would hit capacity planning out of the park! I've show it to a few people in the PM org here and we all like what we see, but it needs a few tweaks to be truly stellar!
Thanks for sharing this idea! When you change a record's start/end date, each team's estimate for that record should move as well. Can you share an example or possible a screenshot of what is going on so that we can learn more? Thank you!