Setting up "landing Projects" for Agile Team

[TeriCh]

We are new to Agile teams and trying to figure out best practice in workfront - but here is where we are: 1. Created a Request Q to have all issues (stories) from users regarding an application we manage - these issues are routed to a LANDING project(s) for the Application(s) {we have about 100 apps that our agile team works on - so we have 100 of the Landing projects} and assigned to an Agile team we set up. 2. The Agile team creates iterations, works through them and eventually completes the iteration, The question I have is regarding the Landing Project(s) - these will never have tasks - only issues that get routed to them so we can track each "Application" and the issues associated with them. How should we set up these projects - Start from or Completion date ? as we want them to be open for at least 15 years into the future. Any thoughts or suggestions? Teri Chisholm Harvard Alumni Affairs and Development

[ErinRe]

Hi Teri, I have a couple of thoughts... you could create a project status of "Ongoing" to use for these perpetual Landing projects whether you use Ongoing or In Progress as the project status, you can change the condition mode to "Manual" and then set it to "On Track" so it isn't showing up negatively on project health reports, etc What are you looking to accomplish with the schedule from start vs. end date? Im thinking it makes sense to schedule from the Start Date. Our implementation consultant said that scheduling from completion can have other wonky impacts so that is in the back of my mind (haven't validated, we rarely, if ever, use this setting), but also wondering what benefit the schedule from completion date would have. Once a task is moved into an iteration, the dates are set by the iteration so I am assuming the same is true for issues? Traditional calculated project dates really get thrown off when planning via iterations. Alternatively, you could add one Task on the project that is just the "master" task from the project start date to your projected end - set the start date and the planned hours that get you to today+15 years. This will help reflect that the project is open in perpetuity. Another alternative could be to open a new project each fiscal year. Not sure if this would just create more work for you to update the routing rules, and reporting, etc. It would give you a specific point in time to re-review the items on the issues list (the backlog essentially) and clear out anything that is no longer relevant, copy anything forward that you do want to keep, and keep the overall project list to a manageable number of items vs growing it to hundreds or thousands over time? We dont have the exact use case you are describing for intake of our agile work so Im not sure how applicable these ideas are. Id be happy to brainstorm more if you want! -Erin ERIN REED National Heritage Academies, Inc.

[VicAl]

Yeah definitely Start from. Though if you have no Tasks it may not matter much anyway. But only use "from Completion Date" if you're a masochist �� . With Agile it's important to remember that the Landing Project is really just a holding place and rarely used or viewed (except for access levels). The Team Assignment is what drives all your Agile work (Backlog, Iterations, etc.). You don't even need a Landing Project for each App. We set them up by each Team (and each Team has several Apps they support). And frankly we could really have just one landing project. But it comes in handy when setting access levels for the Tasks/Issues and helps prevent you from reaching the 50K object limit. So you might rethink having so many landing projects (or just leave it alone if you don't want to mess with it). If you're doing that to report on various Apps (i.e. which Apps are getting the most tickets) we do that be having a custom App field in the Request queue menu (see attached). We only expose the apps of the team selected. Then we can run pie charts on the app field to see which are getting the most tickets and find out why. Hope that helps.

[JohnAl1]

I second what Erin and Vic mentioned - Start From date and absolutely make it a Manual condition. John Albaugh