Practical questions about ActivityTimeline app production usage

[Shawn Syms]

Greetings. I am looking for configuration and process advice from anyone using the ActivityTimeline app for resource/capacity management.

It appears there are two ways to configure how ActivityTimeline displays tasks in user's timelines in the Planner view: what I will call Sprint Mode or Non-Sprint Mode (by "Sprint Mode," I mean that you have selected the configuration option: "Show issues based on their Sprint: Issues will automatically appear on the timeline of Assignee user between Start/End dates of a Sprint if enabled.")

From what I have seen so far, both approaches have a lot of drawbacks. I am hoping someone can enlighten me about the more efficient way to use this software.

SPRINT MODE

If you have selected Sprint Mode, then all Jira issues that are a part of a sprint will appear on user's timelines during the two-week window of the sprint -- as long as the Jira issues have been assigned to a user, of course.

What's good about this is that all of the sprint's Jira issues appear in the right place in user's timelines without having to specify start/end dates on every individual Jira issue. That is great.

But what is bad about it is the following:

-- every single Jira issue that is part of the sprint and is assigned to a user will appear on the timeline and be calculated as part of the user's workload

-- this includes Epics, which are just containers for other issues and don't need to clutter up the timeline (and if the Epic itself has an effort estimate, adding that to an individual user's workload calculation will inflate it inaccurately)

-- this also includes issues which are already completed and marked as done, which should not count toward the user's workload since they are finished

-- this also includes issues that we have marked as Backlog, which means it is not expected that the user will get to them during the actual sprint, so they should not count toward the user's workload

--  this also includes issues that we have marked as Blocked, which means the user cannot currently work on them, so they should not count toward the user's current workload

-- it seems like the only way to get these issues out of the user's timelines in ActivityTimeline Sprint Mode would be to unassign them to the user, which we don't really want to do, since that would remove valuable information about those issues in Jira (ie, we don't want to actually unassign them to the user, we just don't want them appearing in the timeline if these are logically tickets that wouldn't be actually worked on during the sprint).

So Sprint Mode is the easiest way to get most of the Jira issues appearing in the right place in user's timeline -- but it also adds Jira issues that logically should not be there, which inaccurately inflates the user's apparent workload, and there doesn't appear to be an easy way to specify excluding some of these issues.

NON-SPRINT MODE

In Non-Sprint Mode, every single Jira issue has to have its own start date/end date/effort estimate in order to meaningfully show up in the user's timelines in the right place on the calendar. 

And in order to maintain accuracy of the user's timeline, every week our project managers would need to update the start date and end date of every single Jira issue that has not yet been completed. 

Either way just seems like a huge amount of work. Is there something that I am missing here, or some better approach that anyone could recommend to me? My goal is to implement a resource-management process using ActivityTimeline that minimizes the amount of manual effort involved.

Thank you for any advice!

[Svitlana Samotis]

Hi @Shawn Syms

Your detailed explanation of the challenges you’ve encountered with both Sprint Mode and Non-Sprint Mode is greatly appreciated, and I’m here to offer some recommendations to streamline your resource-management process while minimizing manual effort:

Epics and Double Estimation:
To mitigate concerns regarding Epics and double estimation, I recommend adopting a unified estimation approach (Estimating tasks rather than Epics or storing estimates for an epic in another field (Remaining Estimate should be empty) or assigning Epics at the team level rather than the user level. This ensures accurate workload calculations without unnecessary inflation.

Resolved Tasks:
ActivityTimeline offers configuration options to manage resolved tasks in users’ timelines (Configurations -> Timeline Panel -> Displaying of Resolved Tickets). You can choose to hide resolved tasks from the timeline or display them while ignoring estimates, ensuring that completed work doesn’t contribute to current workload calculations. 

Blocked Tasks:
Similarly, for blocked tasks, marking them as resolved in ActivityTimeline and utilizing the same configuration approach can streamline workload management (Configurations -> Timeline Panel -> Issue statuses to mark as Resolved). This ensures that blocked tasks don’t impact current workload calculations unnecessarily.

Backlog Management:
Regarding backlog items, I recommend moving them to a future sprint. Issues in the backlog shouldn’t be included in active sprint calculations to maintain workload accuracy.

It is worth mentioning that even if you’re using sprint mode, you can set specific Start/End dates for any Epic or task. This way, tasks show up based on these dates instead of the sprint dates, making it easier for teams using different approaches to work effectively with ActivityTimeline.

Should you require further assistance or guidance on implementing these recommendations, consider scheduling a short call with our product experts. 

Svitlana, ActivityTimeline Team