Workload Distribution with Rapid Board Plan Mode?

[Emanuel Wlaschitz]

We recently switched back from Rapid Board to the Classic Planning/Task Boards because the Plan Mode is simply not useful for our needs (yet).

Our main problem with the plan mode is that we cannot see how the workload of selected issues is distributed (like, does one developer have 20 issues with 4w of work while another only has 3 issues with 2d), in order to make sure that noone is bored nor overly stressed during the sprint.
The classic Planning Board allows this to some degree, as it shows all Users at the side when switching to the Assignee view (which is still a bit problematic, as it shows all users, not just the ones that have tasks and/or are part of the project).

What we could use there is a view similar to the Planning Board Assignee view that comes up when selecting issues - one that shows all users with tasks for the planned sprint, aswell as a summary of how many issues and/or how much estimated time it should be (and a really nice-to-have one: set weights for part-timers/externals and constraints or some other sort of visualization that indicates a high workload compared to others).

But, until that happens: How are you handling this with the current Plan Mode (GH v6.0.1 as I'm writing this)?
Note that we have to deal with specialization, so we cannot just go and use unassigned issues, nor have everyone deal with any kind of issue.

[James Sandlin]

This problem has not been resolved and therefore I continue to use Classic mode. Until I can plan for my team and see the number of points assigned this sprint, I will continue to use Classic.

Every team at my company uses a whiteboard and lists out team members and their workload. Are you kidding me? Atlassian chooses to sell a replacement which regresses users to using a whiteboard for planning?

I have been administering JIRA, Greenhopper, Confluence for 6 yrs and am an avid proponent of Atlassian's products. However, if Classic is removed before the Planning Board functionality is ported to the new boards, I will approve developer's begging to switch to Rally.

[Emanuel Wlaschitz]

Thats what we do right now...one parent version with sub-sprint-versions. And using the planning board, we filter to those to get our workload-per-person summary (the idea would be to use the time estimate in the future, but for now our tickets barely ever have a useful estimate; we're still working on that).

Basically, we want something similar for the RapidBoard (because it supports multiple projects at once) - specifically the Planning Board in the Plan Mode that gives us an advance view of how its gonna be before actually starting a new sprint.

[boardtc]

As regards helping an overall progress have you considered setting it up so that your backlog is the parent of the various fixVersion sprints. That way you can look at a burndown on the backlog children and see the overall burndown of story points.

That does not give you a breakdown per user and you may not use story points!

The more I think about it I think you need a RapidBoard, which can span multi projects, and has a default view to see "my issues", just like a classic task board does BUT it canspan multi projects. Of course this will only give a task list and not an estimate total.

[Emanuel Wlaschitz]

Not really, no. boardtc took his time to explain how they do it (and I'm glad that at least one stepped forward to present their approach), but unfortunately this isn't really something that's going to work in our case (not due to technical restrictions tho).

We're still on the classic boards for now, doing it as I explained earlier. Not the best way, but we simply live with it by creating versions and sub-versions for each project that have the same due date. Doesn't help with an overall progress, and people that work on multiple project have the workload problem (they may get heaps of tasks in both projects; making it appear as they don't have much to do in the context of one project, but taking up more time than they could ever do within the sprints if we sum it up).

[Chris Sparling]

Did you ever get an a satisfactory answer to this? I have the exact same problem myself and would be interested to know how people have overcome it.

[boardtc]

We estimate the workload for each person by hand. We use Team calendars to know how many days of the sprint they are available and then we have decide how many hours we assign to each day (to allow for meetings, etc), then we come up with a number of hours manually. This is then comnpared with the number of committed hours.

[Emanuel Wlaschitz]

This sounds interresting, but how does this integrate/associate with the Plan Mode? The main problem there is that the sort field must be the Rank field (which we don't/can't use), or else the draggable bar cannot be used to create a new sprint.

Dragging the bar within Plan Mode, using something else (Classic boards, Issues Filters, maybe the Team calendar) to get the workload, making adjustments back in the Plan Mode etc. switching back and forth is pretty time consuming, which is why we went back to Classic boards in first place (and why I decided to post this question over here).

Assuming you're talking about this Plugin I can't really see how this helps us (versions and sprints have due dates, but mostly not the issues themselves, since they're contained in the version/sprint anyways).

[boardtc]

It doesn't integrate, there is no solution for doing that which I am aware of. I was not suggesting Team Calendars could help in any way on this. I was just describing our manual solution.

I am not undertanding your problem with using Rank, but you could always use Pr# and include that in your filter to order priority.

[Emanuel Wlaschitz]

The problem isn't the rank field, but the fact that the Plan Mode doesn't allow filters other than the rank field. If that worked, we could just use the Classic Planning Board to do some pre-filtering, apply a field/flag to the issues and then use the Plan Mode to kick off the actual sprint.

Still, thank you for taking the time to describe your current solution; but to be honest, I don't think this would work in our environment.

[boardtc]

why can't you saved edit the filter behind the board to add a different sort?

[boardtc]

I think you meant to add a comment rather than an answer....

[boardtc]

I did the same for mine :-)

[Emanuel Wlaschitz]

I was pretty sure I did that; but I wasn't logged in by that time. Converted it to a comment now.

[Emanuel Wlaschitz]

Sorry, but my question was regarding GreenHopper, its Agile "Rapid Board" (as opposed to the "Classic" Planning Board/Task Board/etc) and specifically its "Plan Mode" that allows the planning of a future sprint.

The User Workload Report does not help with Issues that are assigned to this specific and *not yet started* Sprint (which basically means that no values are applied to the selected Issues that would allow filtering on just those).
Right now we simply create versions that describe the sprints and assign Issues to the specific versions, checking workload using the Planning Board or the Workload Report (as you suggested). But with the need to do this over multiple projects with users working on more than one of them, the Rapid Board would really add to our process and show a total workload, plus the much needed feedback "where am I in my sprint?"/"are we gonna make the deadline?".
The main problem here is that we cannot estimate the workload of each person (we do not use the "allow unassigned Issues" feature) *before* starting the Sprint.

[boardtc]

Have you checked out the User Workload Report ?