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 am struggling to figure out how to use Portfolio to do release planning in what I would consider the natural intuitive fashion. In my simple example you can see two issues that I can not figure out how to address. The item listed as priority #10 is scheduled to start before issues 1-9. Secondly, the epic is not completed sequentially. Instead it is split up across several months!
Here is some context to the epics that are contained within this release.
I am relying on Portfolio to use the story point velocity, scoping and priority to suggest the target release. I would have expected that the work would be scheduled in one sprint if each developer is tasked with a single story. Alternatively it would take two sprints by the same developer. However this is not happening. I have experimented with all of the settings and different permutations in Portfolio but I always end up with the same results. This problem is not unique to this one epic/story. It happens with other epics as well that only have a single story. I can only imagine that I am doing something wrong since I can't imagine that this type of scheduling is useful for anyone.
Thank you in advance.
There isn't a lot of detailed documentation on the scheduling algorithm, but her is the link to Atlassian's documentation. Portfolio scheduling-and-timeline documentation
A few things I've learned from trial and error are:
Brian, thank you for this detailed response. This is very helpful. In your first bullet point, you state: "For it to be done at the Epic level, you have to size your Epic so that all linked issues are worked on a the the same time as compared to other Epics". What does "sized right" mean in this setting? I use the Epic Sum Up module and let me Epic add up the effort of all its child issues (stories, tasks or bugs). Do you mean that the effort, be it story points or hours, depending on how I have Portfolio configured, needs to be set at the Epic level always?
By sized right I mean how you group work in Epics so it is delivered at the same time. Portfolio is going to respect the sequence in which you have organized your backlog on your board.
For example lets say we have 400 individual stories we are delivering for version 2.0 of our product. To build an accurate schedule for when each story will be delivered in Portfolio I have to sequence all 400 stories in their backlog... huge pain, right.
We're smarter than that so we use Epic to group stories in to Capabilities, Features, or some other grouping that makes sense, and say we have 40 Epics. Then I can sequence 40 Epics in Portfolio based on what adds the most value to the business. That way if the project gets stopped before I'm done I've already delivered the high value stuff. It's then easy if the business says the world has change Epic ABC is no longer important, instead we need XYZ. You move Epic XYZ up and ABC down in the rank and the stories in the backlog for those Epics are automatically reordered to the new sequence.
Of course you need to make sure you haven't started any of the stories in the Epic you're demoting, but I assume you're only moving things you could.
Now if you're not smart about grouping stories in Epics and say use them to track stories Joe asks about, banking issues, UI changes, or whatever, that is a mix of priority items and only grouped together so you can easily report how many of these are still open but none have to go together. Now my Epic rank in Portfolio is determined by the highest ranking story in the backlog for the Epic. If I move stories Joe ask about above banking issues that means all of Joe's stories move above banking issues which may not be the case. Maybe only some are and some need to be done in three months and the rest are next year. This means I can't move my Epics around to reorganize the sequence of my backlog, instead I have to sequence all 400 stories. The next downside this causes in Portfolio is the timeline view shows you when an Epic starts and is a solid bar until it finishes. So lets say I need to do 1 story from each Epic right now and then it is a mix of stories from different Epics until I finish version 2.0 with 1 story from each Epic. Portfolio will show all Epics Starting and Finishing together. I won't easily know what work is being delivered when unless I look at the story level. Plus if the business says swap feature ABC for XWZ I have to find all the individual stories that make that up and move them individually in my backlog.
Before we used Portfolio it never mattered, so we grouped things in a way that made it easier for us to report on. Once we started to use Portfolio we realized there are lots of ways to report on a group of tickets, but there is only one way to mange the sequence of a group of stories from Portfolio and that using Epic and setting the sequence.
Hope this helps.
Jira is a wonderful highly flexible and easy to configure software, but there is some stuff that if you don't use as intended you have no other way to get that functionality. I stub my toes on that all the time.
I have been told that in order to properly use Portfolio to manage your schedule and backlog, you have to prioritize by Story alone - not Epic. This is difficult, if not impossible for my business as we do not have a good way to organize Stories in a consistent way throughout our project. I was operating under the notion that Stories grouped under an Epic would inherit the relative Epic priority, but evidently that is not the case. It would be great to know if you organize by story alone that you can actually use Portfolio. I have yet to prove this myself.
So, yesterday I created a project and a few stories to test this, as I also read somewhere.
Result: same problem. Inumerous tests, configurations.. always the same.
One of the most simple tests I've made that shows the problem:
- one new portfolio for a new test project
- team with just one person, capacity = 40 hours a week (1 week scrum)
- some stories with 21 hours each
- one story per week
- remaining capacity of 19 hours a week! Incredible..
- if you have the last story of your backlog with less than 19 hours, it will put it in front of all the others..
If you look at your scope table issue order (when all sorting is turned off), is the story order as you'd like it to be? 'Priority' of issues is derived from the story level, so give this a check and make sure they are in the order of priority you want.
I would also recommend making manual release assignments for your issues, given you have them set up. Especially if you have an expectation that certain issues should be done as part of a particular release. You don't have to do this, but it will 'force' issues that are assigned to a release to be done in the fixed timeframe you've set on the release.
In combination with story 'ranking' (or priority), you should get the result you're looking for.
Please don't hesitate if you have any other questions at all and please let me know if this works for you.