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
We are somewhat new to Jira Portfolio, haven't 100% implemented it in the company yet, still in early stages.
We have periodically meetings discussing roadmaps across teams and Portfolio should be perfect for the job. We have imported all the epics from our projects and they can be prioritized by rank. Portfolio will then schedule all work in unplanned sprints and coordinate this dependent on how much resources it has available.
Jira Portfolio will then try to schedule so that capacity utilization is 100% in each sprint.
However, we also have a rule that all teams should use at least 20% of their time doing bugs/support and 80% doing roadmap work.
Bugs/support is work that you usually don't know about in long-term. They are prioritized in a backlog but this is always subject to change. When planning future sprints we can usually lock down sprint 1 with manually assigning 20% to bugs/support and then Portfolio fills up the rest of the sprint.
But in the coming sprints 2,3,4 and 5 the 20% bugs are not allocated so portfolio is scheduling 100% of the work to roadmap work. This will give us a false velocity report, because we know that these sprints will contain issues not defined in the roadmap. How can we get JIRA portfolio to plan for 80% capacity in the future sprints?
Is this a completely wrong approach by us?
Should we just lower the teams available working hours on the roadmap work and keep the bugs/support issues OUTSIDE of the sprints? That would solve it, but then we would need to maintain two different views/sprints. One for maintenance, and one for roadmap work.
How do others solve this? Is there a best practice?
Thanks for the detailed use case! It does make sense to me and I would not recommend taking the bugs out of your JIRA sprint boards in that case.
This is definitely not fully supported by Portfolio but is still possible with a one-time little extra effort. The goal here gonna be to let your plan be about planning (As it is now but without the bugs):
You can also consider voting for the following feature suggestion: https://jira.atlassian.com/browse/JPOSERVER-1546
Let us know how it goes!
I was looking into this approach and wondering if I could use it for my case, not so sure if I am understanding it correctly.
I intended to plan 80% of the available time of my team myself, and let Portfolio plan the other 20%, with the open issues (taking into account the availabilities of the teammembers).
Is that possible with the same approach?
I got one.
Forget Scrum. Change your teams to Kanban, prioritise everything using Jira portfolio. Solved.
You can name this process: [your company name here] Scrum and do the ceremonies that fit your company, on the time that they actually add value to your team.
Need a refinement meeting? set it up. Dont need it? dont have it.
Planning meeting is history, retrospective, move them to once a month.