It seems that if I have a developer assigned to two different teams and indicate the developer's availability as 40 hrs/week on each team, the scheduling algorithm does nothing to assure that developer isn't booked for 80 hrs/week. While the ability to indicate a specific number of hours per week to a team, that only seems useful when the sequence/timing of each project is already known. I'm, however, expecting/needing P4J to honor a specified capacity per resource — taking that into account when building the plan — so that I can truly benefit from the tool's ability to offer a draft plan.
cc: @Martin Suntinger
I watched this question, I might be able to provide some help but I am not so sure about this.
I do know Martin follows the JPO project in jira.atlassian.com as well as the LinkedIn group for Portfolio. I am not sure if he'll get hit by your @mention here.
Hey @Rick Crow, sorry, this drowned within lots of notifications - I have the topic on my radar now, but no immediate solution approach: Portfolio is currently only scheduling based on the weekly hours of each member in each team, there is no "overall total", or any concept of a dynamic allocation. The underlying assumption is that team composition is quite static (keep productive teams stable), and rather the topic allocation shifts between teams. Is the background of this that you form project teams on demand for particular projects and want to figure out how to best staff those teams?
@Martin Suntinger No worries ... I'm sure your inbox is a crazy place! To your question ... yes, given the nature of our environment, teams are formed as necessary once initiatives are identified for a given period of time. While the makeup of those teams are often similar, the size of the teams will change based upon the nature of the initiative. Our hope has been that we could model teams for each of the proposed initiatives in the portfolio backlog and see what J4P would suggest as a workable plan. Having since worked through this with support and now understanding that this is the same behavior seen in 1.x, we're taking a different approach and have simply created one, large team including all available resources. We can then ensure no overbooking and can work through the process of manually selecting the appropriate team members for each initiative. Not ideal, as it bypasses the direct connection of teams/boards/velocity ... but seems like the best alternative approach for us at this point.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG