27 min read

Unflipping the Table with Portfolio for Jira

Oct 5, 2018 11:00:00 AM


Portfolio for Jira provides visibility of work breakdown and execution, estimation of project completion, and short-, mid-, and long-term scenario planning. While it is simple to use and integrate, even the experts like us have moments where we want to flip the table. Portfolio for Jira expert Amanda Babb will take us through some of the Common Behaviors of the Scheduling Algorithm and other Bad Behaviors which will have a critical impact on the use and adoption of Portfolio for Jira.  Whether you’re a current Portfolio for Jira user, or you’re evaluating it for your organization, you’ll want to attend this webinar to make the most out of your experience.  

Full Transcript:

Welcome back everybody! Today we have a really interesting topic: Unflipping the table with Portfolio for Jira. Let's get started.

On the webinar today we have Amanda Babb, Principal Consultant: she's got extensive experience helping teams adopt Scale Agile and Portfolio for Jira; and I'm Joseph Lane Managing Partner.

Let's do some quick housekeeping: no doubt you'll have questions and when you do, use the control panel on the side of your screen to ask them we'll get to your questions as fast as we can and if we can't get to them during the webinar we'll follow up with answers as soon as possible.

On the next webinar, Chris Pepe, our Dragon of the West, will be sharing his experiences and best practices around migrating the Atlassian Tools within AWS.

It'll be on Wednesday November 5th at 11 a.m. Central.

Let me first take a moment to tell you about us here at Praecipio Consulting: we're an Atlassian Platinum Solutions Partner, one of 14 Platinum Solutions Partners in the country. Over 99% of our projects are Atlassian related, which includes everything from DevOps and IT Ops to Agile SAFe Solutions.

We have hundreds of clients across the United States ranging from small and medium businesses to the Fortune Five. Our clients include the top retailer in, the world the top media companies, the top automotive retailers and the largest healthcare services company and electronics manufacturer.

And now let's hear it from Amanda Babb:

Again my name is Amanda Babb, I'm a principal consultant here at Praecipio Consulting, and I'm really excited to talk to you again today about Portfolio for Jira! So let's go ahead and get started.

What we're gonna cover today is, of course you know what Portfolio for Jira is, we're gonna do a real brief conversation around the tool and what it does. Then we're gonna move into Unflipping the Table with this Scheduling algorithm.

I always get a lot of questions during client implementations around what exactly it is, how it works, all of that wonderful stuff: We'll walk through some of the common bad behaviors we've seen with data and how clients have actually used the tools, and then of course at the end we'll talk about a time when we worked with a client to implement the tool to solve a specific problem.

So with that being said: What exactly is Portfolio for Jira?  Well of course you've probably seen it, it's considered a planning and road-mapping tool and really what's fantastic about it is its flexibility and its ability for it to work with your data. To understand planning and road-mapping in real time, well you've probably seen a lot of demonstrations like this, right, where everything is relatively simple. It's very pretty you see the nice red/green scheduling line when the pieces of work are expanded you get to see all the details down to the story level, all of the releases are tagged, you've got a lot of work that's with dates and statuses and everything's marked with themes and then you can see the actual end dates of when things are supposed to be done.

Calculating the plan is relatively simple as well it, makes it really easy for you to go ahead and run the plan right. So you've probably seen this as well, and you've probably seen a lot of demonstrations like this right where everything is relatively simple, it's very pretty, you see the nice red green scheduling line when the pieces of work are expanded, you get to see all the details down to the story level. All of the releases are tagged, you've got a lot of work that's with dates and statuses, and everything's marked with themes and then you can see the actual end dates of when things are supposed to be done.

Calculating the plan is relatively simple as well, makes it really easy for you to go ahead and run the plan right? So you've probably seen this, and you've been super excited about it; you may have even installed an evaluation license.  You probably even went through training and well you end up with what we call the table flip moment, cuz your plan probably looks like this and it's makes absolutely no sense and your plan is doing quote weird things unquote right?

So raise your hand if you're missing work in your schedule? You've calculated your plan only to see everything change. You're starting to see items in your plan that you know are actually done, you've looked at the Jira data and you still don't understand why it's putting something there, and you've struggled with adoption Portfolio for Jira because you mean just not understand exactly what's going on.

You can put your hands down now, I know at least some of you out there have your hands up. So this is one of my all-time favorite phrases from one of our clients that she came up with when describing Portfolio for Jira : “just because it's inconvenient doesn't mean it's not true”. A lot of the behaviors, a lot of the things that you see in Portfolio for Jira are actually true representations of your data and I'd say that probably 80% of the time this holds true. But if you apply the Pareto principle of root-cause analysis then we know that 20% of our issue is actually causing 80% of our problems in Portfolio for Jira.

So with that being said let's actually do a little bit of a deep dive into the scheduling algorithm for Portfolio for Jira in order to unclip this table. So when working with Portfolio for Jira it's important to understand the main scheduling constraints. Here we actually see the primary constraints

they're not necessarily in any particular order, you have item right basically where it is in the list from 1 through n. You have estimation, so whether or not things are estimated or not estimated. And then of course team velocity, so what the previous velocity has been of the team predicted going forward and then of course things like child estimates will actually roll up to parents and that velocity will be applied.

These are your primary scheduling constraints and what's great is that there are a bunch of other things as well, right, so there's other constraints and some of these we’ll actually examine

in depth later on during this webinar. But things like dependencies or availability of team members, stages, so I'd like to refer to that as pre work or work to do the work. Are you working with earliest start dates? Things like sprint assignments are explicit sprint assignments: all of these things like release assignments all of these are things that could actually impact what you're seeing in the schedule.

So let's dig a little bit deeper into the item ranked piece. Again something you've probably seen before. We're moving down into the epic level and here you see this website structure epic, it's ranked number four, we see some of its information in here; but in the schedule it's showing kind of in this upper left corner above something that's actually the number one ranked item!

So why is this happening? Well, it's a sign of the MVP release. We don't have an estimate on it,  well okay, we've got some scheduled start and end dates again it's number four, why is it in that upper left corner? So we recalculate this and we get this table flip, we're now it's all the way back in 2016 so if you take a look at the scheduling factors within this particular item this is why this is happening: you have a target start date at the fourth of December 16, 2016 and the 16th of October of 2018, so how do I move it later? Move the target start date. What does that mean? How did this date happen in the first place? And again this is an explicit assignment, so at some point somebody set targets on this particular item and then went ahead and committed them back down to Jira.

So now we've got this scheduling item that pretty much this epic understands it's start and end date because of those committed dates. From the ranking perspective we rank the item in the plan and see what happens there. Here's our website structure epic and we're gonna go ahead and drag it down of course it's gonna take me a couple of tries to get it all the way down to the bottom and if you have really large plans this is probably gonna be even more difficult for you, so this basically says hey, keep your queue length small.

So we've dragged it down you hit recalculate and it didn't move! It's still in this upper left-hand corner! So why is it there? Looking into the details what we see is our scheduling factors, the most important is that it's assigned to the release MVP and the least important are those target dates. Ok well that seems reasonable, so let's go ahead and just have the plan calculate their lease! You press the calculate button and: randomness again. Table flip moment: why is this happening?

All right so, looking into the details and looking into you the scheduling factor here, why is it there? It's those target dates of back in December of 2016! How do I move it later? I have to move the target start day. So at some point in time somebody has committed these dates and now this item in Jira as well as in the plan itself, is interpreting this start and end.

So in this particular case again we're still talking about this item rank thing, right, we're still seeing this bad boy here in this upper left hand corner and we really actually want this thing to go someplace else, so if it's most important scheduling factor is the fact that it's assigned to a release, we saw what happened when it was calculated.

So let's actually go into the epic in Jira. Here are we seeing that that it's assigned to that fixed version aka that release, we're gonna go ahead and we're going to take that out. Then we're gonna pop back over to the plan, and as we're doing that we're crossing our fingers and hoping that everything's gonna be good because we made a change you want to calculate to pull this new information back in.

And there it is again! Why does it keep doing this? I don't understand! it's okay, it's because of these target dates that were committed at some point in time down to the issue itself. We need to move that target start date back.

So with that being, said some of the key things that you may see when you're trying to work with the item rank piece within a plan in Portfolio, is first: target schedules, those committed dates that we kept seeing, that's going to override your item rank. Release it so your release dates will also or could also possibly override item rank and then that that concept of the explicit dates. So if dates were committed and an estimate is missing, dates will override the rank, okay? So these are all things in the schedule and the scheduling algorithm that could happen.

Let's go ahead and take a look at estimation at this point. One of the things that is key to remember here is that if an item does not have a release nor an estimate is that it's not going to show up in the schedule itself. So keep that in mind as we move forward and we start looking at some examples of fun things that can happen here. So I'm about to do a magic trick for you and this is one of the things that I absolutely love and adore about Portfolio: at this point in time if we go ahead and we apply an estimate to the same epic that we were working with with this item rank piece and then we go ahead and calculate the plan where did it put it? Exactly where we would expect to see it in the schedule and of course our release is going to be late right?

So we're seeing this red factor and now we're seeing their scheduled factors what's most important is that it's a sign of the MVP and it's ranked at position number four in the backlog. How can I move it later? And now we actually have options! We can move it lower in the backlog. We can set the earliest start date. We can add a dependency. All we've done is put an estimate in place. That's it! So the key here to remember is is that even though swags may not be something that you're comfortable with if, you put them in place your plans will react the way that you'd like to see them react.

So by default plans use the same configuration, so when we pop into the configuration menu and we use this scheduling piece one of the important things to remember is that based on target dates is the default behavior for the plan, so I've gone ahead and I've switched this over to default estimates and now we're gonna go back to the plan. And anytime you make any of these changes you are gonna want to make sure that you recalculate the plan.

What happened? We see the exact same behavior that we saw before our website structure epic is now scheduled and ranked properly. What's the most important is that it's assigned to this release the MVP least important is the fact that it's ranked number four, but again if I want to move this thing later, I have the options to do so so this is something that's very key in if you set default estimates that will override that target behavior.

So planning, I mean planning in Portfolio for Jira, is kind of a big deal, and it's probably one of the reasons that you'd like to use the tool. So I'm gonna go ahead and insert an epic here right? And I'm gonna call this very IRA or generically new web epic, woohoo.

Because of that I'm gonna go ahead and calculate it and, now I'm seeing it but it's not where I want it in the schedule of my default estimate set, so it is it is estimated what do I need to do I either need to move this higher in the backlog or assign an earlier release. We see that it's got the synch up on this later release so I'm gonna switch that to MVP and hit calculate, and it's exactly now where I would expect to see it.

The work is estimated, it's assigned to an earlier release and this is now basically my plan in terms of this piece of work that may have come in and is now more reprioritized to be higher in terms of work that needs to actually get done.  It's really that simple: in order to help with planning, and making sure that it's estimated and making sure that it's tagged with a release.

So if we look at estimation in general as some of the things that can help you unflip the table in your plans is estimating if it's a swag it's cool but story points on the epics in the plans make that schedule easier to read and interpret setting default estimates will help you visualize all of the work with default estimates so if you're missing work in your schedule it's probably because there are estimates missing and then if you have both an estimate and a release then you'll have a prettier schedule with work where you want it in that timeline so these are things to remember when you're working with the estimation piece.

So here's primary factor number three team velocity generally for portfolio for Jira will treat velocity as a proxy for capacity but that actually kind of sells it short, so let's go ahead and take a look at some some impacts that you can have to your plan based on velocity. The team's tab is where you go ahead and you set your velocity in here.

We see we have our web scrum board team, it's actually empty, I don't have any team members in here, not trying to show you anything very specific. I'm looking at the past velocity and I'm gonna use that suggested velocity of six points we see right now our timeline 19th March of 2019; overall all of the work is gonna take that long to complete, so I recalculate the plan now that I've tweaked this velocity and we're looking at much lengthier timelines, now we're looking at the 20th of August of 2019. So it's kind of a no-brainer, right, so you have your velocity you decrease it your schedule your timeline lengthened well it did that because we have work estimated as well as our releases tagged to our specific items. If you have those things happening in your scope tab, then changing the velocity will impact the timeline in the schedule, as you wouldn't expect it to see.

So on this next one we're gonna see, you know something very similar, what happens when we go ahead and increase velocity; and what's pretty fantastic is you don't have to use the board you can manually enter these things so I'm just gonna use my my epic velocity of 35, and just again here we see it's the 19th of March of 2019, and I'm gonna go ahead and calculate it.

Now this is the thing is that the timeline didn't change, but it basically tells us that the web team is gonna be out of work the 19th of February of 2019. Because the app teams work didn't move that was a real quick sort of show on that.  Even though my overall timeline did not change, all of the work for the web team actually got shorter, so it accurately scheduled this. And this is exactly what we want to see on a regular basis.

To that extent some of the keys to unflipping the table here with velocity, I mean it's it's pretty simple: if you reduce the velocity, then your timeline will lengthen; if you increase your velocity then your timeline will shorten: you've got that inverse relationship between the two.

Now that we've seen a little bit more around how portfolio works and kind of why let's go ahead and take a look at bad behaviors and these are some of the things that we've seen clients do or teams do at client sites in working with Portfolio for Jira that we want to avoid.

So the first one this is my personal favorite: it's referred to as "the groomed sprint". So if you have a scrum board that, let's say, has a very large product backlog: 150 200 items, sometimes what we'll see is that the team will actually use a Groomed Sprint to split up the backlog to help them better visualize exactly what that information is in and what's been estimated and grouped. Here we're seeing the play in itself, right, so we've got this initiative layer and we're gonna look at the top layer of the hierarchy because of the way that this will impact things. We see here March 2019, that's basically when it's estimating this thing to be complete based on the velocity and the estimates. We see that we've got a nice mix of work from both teams and then we'll flip over to the capacity view. So the app team under App Sprint 1 is actually currently estimated that they're going to play in for 28 points during this sprint. Alright so we go over their scrum board we see App Sprint 1 we see this wonderfully groomed work and then we have this estimate here of 28 points.

Cool so let's say the team goes ahead and creates this new sprint that they're gonna call the Groomed Sprint, and then they're gonna take this little handle bar here guy and create a sprint right? So dragging all this information down, voila! You now have this groomed sprint with an estimate of 56 points! Okay, cool, so if we go back to the plan and we hit calculate, all of a sudden we see this Groomed Sprint that's loaded to five hundred and sixty percent because ten is really what they're supposed to be performing on a regular basis. Then if we look at our schedule, we go back to this launch new customer care portal, we've now basically said this thing's gonna be done on the 22nd of January 2019, almost two full months ahead of what the previously predicted date is! So if teams are creating Sprint's just to understand what their backlog is, the plan will not override that, it's considered an explicit assignment. You're gonna need to retrain some folks about their behaviors, and do some other things there and we'll talk about what you can do in order to prevents these things.

So this is another one that I see a lot of customers and clients flipping the table around, which is: "I promise we did everything that we were supposed to do Amanda! We even released all of our versions in Jira and we're still seeing work I don't understand!" So this is kind of a fun one, and what we're gonna do here is we're actually gonna look at the releases tab. Over here we see this cross project release, MVP, we see that it's red so it's late, we see specifically the web part of the release, and if we actually go up here to edit, again we see that it's overbooked! It's told us at least four times if this thing is overbooked! So let's view the version actually within Jira itself. So we see up top it's released it was released back in January of 2017, but you have three items that are still outstanding on this release, so these three items are all in that open status. They were not completed. So of course the question is why did you release? You have work that is not done that has not been completed! Why did you actually release this version? It's not done right! You still have open work here! so there's a couple of things here that you can do and this is why your release is showing up and why it's late in your plan even though you've already released. This is basically now you have to move this work somehow, right? There are a couple of different ways you can do that, you can either retag it with a later version, remove the current version, or unreleased this particular release, because it's not done! There's still a bunch of work to do!

So this is also an another fun one: where somebody says "I've got a dependency! Why is this happening? Like, why is it scheduling this the way that it is?" And a lot of it has to do with harkening back to that first phrase: "Just because it's inconvenient doesn't mean it's not true". So let's take a look at this one: so we have these two we're at the epic layer, sorry just to remind you of that, and we have these two items here. We've got this create mobile view landing page, and this create new landing page, and these two things are dependent on one another, but your app 19 piece, which is supposedly being blocked by web 24, is scheduled ahead of web 24 so you're seeing it much further to the left in the schedule where you'd expect to see it right in the schedule, because you have a dependency!

So if we actually look at the epic itself and we take a look: here's our here's our link, here's our dependency, that it's supposedly blocked by web 24, this is where the key comes in! This lovely little guy right here, this profile image, doesn't load. It's considered on hold which is a yellow in progress status color, and basically what it says is "this work is essentially in progress." Now I'm gonna go ahead and say: let's move it back to that open status, let's not even bring it into into work, it's not anything we're working on, so let's move it back to open".  This is where the key comes in, is that if we go back to the plan and we hit calculate and then we look at our dependencies again it didn't move it, it's still in the exact same place it was.

This is an extreme table flip moment, and let me let you know why this is happening: it doesn't matter that the work is currently in progress, remember that on-hold issue that we saw that on hold story; what it matters is it is if any of those stories had ever been in progress then that basically means that the execution has been actually reprioritized ahead of the previous one.

Looking at this from a bad behaviors perspective, you know, how do you counteract some of these bad behaviors that we talked about? So the Groomed Sprint: just go in and clean up your backlog! Resolve your outstanding items, don't put them in things like Groomed Sprints, get them off your boards! They don't disappear, they're not deleted, they will come back at any given time because you can run queries on them. They're just not showing in your board.

The other thing about these release pieces. You've released a bunch of work however all of the work may not have been completed in the release. So either don't release a or undo the release, or move the to do and progress issues into a later release. So essentially retag the work. And then last but not least this whole dependency piece is that if work is in progress or ever has been in progress, Portfolio will generally reschedule and reprioritize that work.

So now we're here at our favorite section of all of our webinars, it's when we talk about a client issue that we saw and how we helped them solve it with Portfolio for Jira. In this particular case, we're gonna be talking about a Fortune 20 retailer. What was pretty amazing is that for one of their very large portions their organization, they were running all of their planning and execution actually in the one dot or classic plans in portfolio for Jira. It just hadn't gotten to you the Live Plans piece, and they've been running this way for about a year, actually now that I think about it, probably about eighteen months! Their work in general was aligned to strategic themes, so all of their initiatives fell under a particular strategic team, and that was what they would use to report to things like Wall Street about when they thought work would be done. But their teams were actually aligned to trains, Agile Release trains, so you've got kind of this blending of vertical and horizontal. And what were exactly how are we gonna go ahead and help them understand and visualize their work in this particular area. They knew that they were splitting that the capacity of the teams across those strategic themes, so a team may actually show up in multiple plans. What's really cool is that they have really really high Jira discipline, these are folks that have been using Jira for a long time, as well as the fact that they had a really good Scaled Agile Frameworks for the Enterprise maturity, and after the solution they were trying to also determine whether or not this was a tool to roll out to the enterprise as as a whole. Could this be something that could help the entire enterprise?

So how did we go ahead and solve this? Well the first piece is is that we ended up having to build our plans based on filters, and using those shared teams. We were able to split teams essentially across the plans and still connect them to their work in Jira, so that you can see the actual execution of the work against these strategic themes. To that extent of course we had a plan with strategic themes, so each plan in Portfolio for Jira was representative of one of those strategic themes. We also helped them roll all that information together into a program, within Portfolio for Jira, so that they could just look across all all the strategic themes at any given time and see where they were in the timelines for each of those things. That also gave them the opportunity to do some reprioritization as needed.

And of course that helped the maintained planning flexibility! When it came to bringing new work into the plans, it was by strategic theme and based on the velocity that they were willing to allocate to that particular strategic theme by any given team or team of teams. Then they were able to say more effectively when something new that was coming to them could actually be done, and then actually we're currently engaged with them. And we have kind of this ongoing implementation of the enterprise where other groups are now asking to be on board and into their plans. So a really cool success story and I really enjoy this one particular effort.

Well with that being said, we always get a lot of questions about Portfolio for Jira! I'm sure that there's been a bunch of those coming in from all kinds of areas, so let's go ahead and start running through them.

All right so we have about a half a dozen questions, we got some time to walk through these. So I'm gonna go through one by one and of course if any more come in you know, please don't hesitate to ask, and like we stated before if those questions don't get answered, well we'll go ahead and we'll send out those answers once we actually got the webinar all recorded and everything.

So that being said, the biggest question that I've been receiving more recently is, kind of what's next for the product? What's the next kind of big deal coming with Portfolio for Jira? And I'm allowed to say, and I'm kind of excited to say that I was able to see a brief demonstration of their three dot Alpha release for the product, so there's some really cool features I'm really excited to see. Now because it is an Alpha, there are some early access programs, some customer interaction with Atlassian with the new product and kind of getting feedback from customers and things like that. So of course as always, no idea when this thing is actually going to be released, but like it looks really cool! I'm really excited, I'm trying to get my hands on it internally so that I can play with it a little bit more. So I'd say probably after the first of the year we might see some some really cool things.

Another big question I get is kind of like what are the other resources that are out there around Portfolio for Jira? You know in terms of: "hey it's great to watch webinars but what else is out there for us as users and evaluators". And I'm happy to say the documentation is has come a long way since it was first since the product is first released in 2014. Definitely look at that. The community is relatively active, the Atlassian community around Portfolio for Jira, because generally there are a lot of questions around it. And then, of course, Atlassian University. There is online self-paced training. And then of course other folk can train as well, and you can always reach out to your friendly neighborhood Platinum Solutions Partner! We'd be more than happy to talk you through some some different things, to help you implement or work with the product itself: so that's fun!

Another question I have here: How do I actually choose what goes into a plan? And I think this is coming actually from our "seen it, solved it" section in the webinar, because that was a relatively complicated implementation that we had to really understand how the teams were contributing value to their customers and so the organization as a whole in comparison to what they were actually doing in Jira. So the "how do I choose what goes into a plan" really is driven on: How is your organization structured? What is it you're really, actually, trying to accomplish as the organization, regardless of how you have Jira set up, regardless of the tooling themselves? How is your organization actually aligned to value?

So that ongoing implementation we were talking about, we have organizations that are kind of aligned in these very broad verticals, and the teams are relatively small in terms of the execution against those verticals, so that actually makes a really easy 1 to 1 in terms of creating a plan for vertical. Makes it super easy, we just basically grab a whole bunch of boards, throw them into a plan, see what happens. They get used to their data: fantastic! But in more complicated implementations, kind of like what we were talking about in that in that Seen it solved it piece, really understanding how the teams are tied to the work itself. And then basically making sure that no matter what, your source data and your teams are intimately tied together. that's probably  the biggest piece of advice I can give folks on a regular basis.

Looks like another one came in around the releases piece! So we saw when we were doing a release that we have, that work that's been released in Jira itself, but we still actually have open work that's associated with that release. Anyway the question is: if my team actually uses releases as basically almost like their commits are like our point releases, so like 1010.1 then 1010.2. Like how how do I bring that into a plan? But still actually make that scheduling timeline makes sense? And really kind of the the bit there is you don't! And I know that's really disheartening to say, but what you need to think about in releases in plans, is what is it that we're actually intending from a product perspective to put in production? Think about working code in production as your definition of done, and that's generally how you you're gonna want to plan any releases. So my best bit of advice there is it's gonna be a bit of a pain: go ahead go into your Jira projects, go to the release hub, and take a look: release old stuff, archive of old stuff, if need be retrain folks on what the actual use of versions should be, and if they're afraid they're gonna lose visibility based on reporting. I mean, again, there's lots of different ways that you can integrate Jira with some of these other source code management and build tools and things like that. To be able to still understand, commit to actual release working code in production.

So you're not gonna lose that visibility, but what you're gonna do is actually minimize the overhead in those Jira projects. So then when you're creating your plans, everything's gonna look a whole heck of a lot cleaner. It's gonna be easier to say: Okay, this is the milestone date we need to hit! Or, "hey, this is the scope of work we need to fit into this specific release"

Let's see: "How can I make this schedule move based on dependent work? So that one was coming kind of out of the the last little bit there from a dependencies piece. So this basically, what I think the question is, is let's say I've got this huge scope of work but I'm also dependent on another team; meaning I have to have infrastructure deployed or they have to complete a bunch of stuff before I can actually move forward with a particular bit of work, whether that's an epic or an initiative. And one of the things that we've recently discovered or that's not really discovered then, we found solutions around, there we go, is that there's kind of levels of maturity of this. So generally the first bit of advice is, make sure you understand how all of your work in your plan works first, and whether or not folks are completing things correctly. Are they actually tagging things correctly? Like all of that. So focus on your own house first.

At the point in time that you're actually ready to bring in work that you depend upon on other teams there are a couple of different ways that you can go about doing that but a lot of it is once it's in, how can I actually impact or move that schedule? That has to do with the dependency itself. You actually have to link the work together. Meaning we were seeing that dependency between I think app 19 and app 24, that link itself has to exist across those two pieces of work in order for that schedule to change. Which means that somebody's got to link those two issues together.

Now if you already have that work tagged and you understand what that work is from that other team or team of teams or whatever that is, then as soon as you visualize that in the plan then you can go ahead and use the plan to just set those dependencies and then commit them to Jira. So it makes it a little bit easier on the end user, they don't have to think about, okay this one is connected to this one, etc. They just basically have to be able to bring the work into the plan and then you would go ahead and link them and push them back down.

So that's kind of one way is that dependency link, the other thing is is depending on the type of work, and whether or not that other part of the organization is using epics, so generally what we're talking about in this case is more of a development organization that's reliant on more of a traditional IT organization. I've got to have these servers deployed, etc... So we're submitting service requests or service tickets to these other folks, well those other folks might not actually be using the concept of an epic, meaning they don't actually group all of their service tickets together into kind of buckets. Totally acceptable! Totally fine! That allows you the opportunity then to take that dependent work and actually use that epic link back to your work, and as that thing gets changed or rescheduled or whatever that is then, how that's going to move that epic or lengthen the timeline on that epic.

Now the only unfortunate part about that is that if they are actually using epics then the problem is you can only have one parent. So in the grand scheme of things if they are, then that's not gonna work for you. You're gonna have to go the dependency route.

That was a really long explanation to basically say link your stuff together! If you got it linked together, it'll move and it'll change in the schedule. As long as you brought it into as part of the source of a plan. That looks like I don't actually have any more questions that have come in from the audience, so I think it's about time for us to go ahead and wrap up. Of course thank you again so much for y'all's attention today, and really appreciate your attendance. Of course if you have any questions or have any other concerns around Portfolio for Jira or any of the Atlassian products please feel free to reach out to us via our website at Praecipio.com, we're available on LinkedIn, Twitter, email: all of that wonderful stuff so thank you again for your attention and have a great day.


Past Webinars

Case Studies