You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I have created a virtual user who is not available during some time. When I am planning my user stories on portfolio, i see that portfolio assigns the user to the user story for a given sprint when he is not available. I have tried to check my configuration but haven't found anything. Does anyone would have any idea on this?
HI @Rohan Jain, is the absence you entered spanning the entire duration of the sprint, or only part of it? By the way Portfolio schedules and displays the data, it is possible that for example a person would be available for 1 day out of a 2 week sprint: portfolio would schedule a small portion of work (1d) into the sprint for that person, but since the display granularity is "sprint by sprint", visually that piece of work would show up for the duration of the complete sprint in the timeline.
The best way to verify if the capacity is correctly adjusted is to switch to the capacity view, and configure the view to "Per member" to see if the capacity for that person is accurate (see also https://confluence.atlassian.com/display/JIRAPortfolioServer/Using+the+capacity+view)
Hello @Martin Suntinger,
Thanks for the answering. I already checked the per member view and in fact user stories were assigned to members when they were completely absent from the sprint. After much clicking and switching tabs, I think I figured out what the issue was. In my backlog, I was always fixing a sprint for an epic/user story and not the release. Since I fixed the sprint and the story exceeded the capacity, members who were not available were assigned the user story. When I fixed the release instead and put sprint assignment to automatic, I did not have this issue anymore. And in case work exceeded, the story was automatically assigned to the next sprint.