Capacity planning in Portfolio

[Martin Søstrand Helgesen]

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?

[Thomas]

Hi @Martin Søstrand Helgesen,

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):

1. Reduce your team velocity in your Portfolio plan to represent your 80%
2. Identify the Board(s) you want to use in your Portfolio plan
3. For each Board, create a Filter that would exclude the unwanted issues (bugs)
   • Typically it would look something like Filter = "Filter for XYZ Board" AND issueType NOT IN ("Bug")
   • Those filters do not need to be shared with the whole team, just the Plan users
4. Create Boards based on those Filters
   • Those board will automatically get the same sprints as the original board and you won't need to create sprints twice for every board, the only difference will be the bugs being filtered out
5. Create (or update) your plan with those new boards

You can also consider voting for the following feature suggestion: https://jira.atlassian.com/browse/JPOSERVER-1546

Let us know how it goes!

Cheers,

Thomas

[Martin Søstrand Helgesen]

Thanks Thomas. This approach could work

[Joshwa Marcalle]

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. 

Solved. 

[Martin Søstrand Helgesen]

and this works for your company?

you are using only portfolio?

I was wondering do exclude Releases from Portfolio and let them live outside

[Joshwa Marcalle]

Hi, 

It works perfectly well now yes. 

I encourage you to read this article for insight

http://obiwansoft.com/problems-with-scrum/

[Jeroen Thoelen]

Hi, 

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? 

[aplantmason]

I think there is an easier way - simply reduce the number of working hours by the percentage of time you want to allocated to bugs, etc.  For example, if you work 8 hour days and you want to allocate 25% to bugs, simply put your working hours as 6 hours.

[Marcus Strandepil]

This works for planning - but it doesn't work when you actually want to work the 8 hours, I think.