Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,556,047
Community Members
 
Community Events
184
Community Groups

Dynamic scheduling vs resource capacity

I have a project schedule which I'm attempting to forecast with the help of Portfolio. However, I'm running into a slight roadblock while using the tool. I have up to three different scenario based plans to help find the team's balance between scope bloat, resource capacity and item estimate/weight.

Initially each of my scenarios had the same total developer(s), total items, item estimates and release parameters (dynamic scheduling) - which resulted in the same release date being scheduled. However, once modifying the resources by scaling their 40hr weekly capacities down to 30, 20 and eventually 0. Portfolio holds to the initial date it had dynamically scheduled. And when adding to the original estimates per item within the stack Portfolio begins flagging random items and notes them as 'cannot be scheduled'.

Shouldn't Portfolio instead tell me that additional sprints are required within my schedule and forecast those items based on estimates and my resource capacity?

My goal is to baseline my ideal target release date then layer in a 'buffer zone' of scope and time based on the amount of bugs typically received during our sprint verification process.

Any advice?

0 comments

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events