Skip to Main Content
Status Future consideration
Created by Gianmarco Spiga
Created on Oct 2, 2020

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

  • Attach files
  • Admin
    Nathaniel Collum
    Reply
    |
    Oct 6, 2020

    Thank you so much for this generous overview! This is very helpful.

  • Gianmarco Spiga
    Reply
    |
    Oct 5, 2020

    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:

    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!

  • Admin
    Nathaniel Collum
    Reply
    |
    Oct 5, 2020

    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!

  • +1