Hi, I'm really happy with the sprint load popup mentioned by Martin. Definitely helps, but leaves a small feature to be desired.

We were discussing the same sort of idea that prompted this post on Stack Exchange:
http://programmers.stackexchange.com/questions/229398/should-we-create-a-story-for-vacation

My team is currently split on our opinion of whether to create stub tickets for non-work time in our sprints. We're slowly adjusting to the idea of having different story point quotas per team member, during each sprint.

• Half of us think that it is useful to see 'non-work time' tickets created and planned into future sprints.

• The other half thinks this is silly and make-work, and agree with the answers to the Stack Exchange post.

The solution so far has been to create an external google spreadsheet that tracks point quotas and the total number per team member, including PTO/travel/other team responsibilities. (gross, right?)

What I want to be able to do is to either define non-working days per team member, or manage story point quotas inside the board configuration. But some teams use time estimates, so down the complexity rabbit hole we go...

-----------

I don't know the answer... but I think that managing non-working days per user would be a step in the right direction. I wouldn't even get into reoccurring or scheduling the days, but just duplicate the calendar picker that is available on Configure > Working Days and let each user set their own days. Not perfect, but certainly narrow in scope?

The non-working days total would be displayed on the Sprint Load popup.

A related feature which helps with the visibility of assigned work for specialists/team members will be released in the upcoming JIRA Agile 6.6 release. Noting here because it has some overlap with the needs of this story and may help with you planning needs:
https://jira.atlassian.com/browse/GHS-9689
Regards,
JIRA Agile team

I would at least like to have the ability to view the total estimated planned capacity for a sprint on the agile board alongside the remaining and total numbers. This way I can have a general idea if our initial ideas of what will be committed to by the team are within reason compared to our estimated planned capacity. We do some more in depth "pre-planning" on what we'd like to pull into a sprint aside from grooming the backlog prior to full team planning/commitment on a sprint.

The lack of this functionality is one of the few remaining blockers keeping me from moving my projects to the new boards.

My teams consist almost entirely of specialists, tickets are assigned to individuals during planning and we need a mechanism to ensure that individuals are not being overloaded, knowing how much time the team as a whole has committed to is insufficient.

In the old system I had a couple of options, In the Classic Task Board I can filter by user and see the total time in the columns, alternatively in the Classic Planning view using contexts (I have a context for each user) I can click on the sprint (version) and get the total time assigned to that user.

I've got too many team members to tally up time manually - I need a way to get a break down of how much time each user has assigned to them before I start the sprint.

Currently, teams working in the Classic planning board will use the Version Workload Report to verify coarse resource leveling for the proposed sprint. I believe this is by tentatively dragging issues into a sprint (fix version), running the report and evaluating the results.

Parent issues are associated with user stories, but prior to allocation to a sprint, those parent issues are broken into subtasks which are a) divided into subtask issue types which correspond to the team notion, b) assigned an original estimate and often, c) assigned to a user.

The version workload report is used to identify the anticipated sprint commitment, per user, in hours, broken out by activity (subtask issue type). This will give us the mix of, say, development and testing activity in the proposed sprint and help us identify any parent issues which create an unbalanced mix based on resource capacity.

Now, the key flaw with this approach - as is - is that it requires a tentative sprint commitment re-evaluated prior to an actual sprint commitment. And of course the classic boards have no way of actually signaling the start of a sprint (leading to extra book-keeping that the rapid boards mercifully handle for us).

Ideally, I'd like to see the right-hand column switch when clicking on the proposed sprint divider to display a breakdown of planning statistics based on a given field - issue type, assignee, Epic, category, etc.

A workaround would be functions to filter on the proposed sprint content(as with GHS-6036) so that we could do secondary analysis on the sprint content using the filter support in the version workload chart gadget (very weak, but Version workload report sadly can't use filters), in the Time Tracking and Billing reports collection, or by just exporting to Excel and running a pivot on the results.