Expand my Community achievements bar.

Working with Agile in WF

Avatar

Level 2
Hello! We are in the steps of replanning a large software implementation project. Internally, our company has been using Workfront for about two years but we do not use the agile functionality. As a part of this particular project, we were working with a third party who used Rally as their tool, and we are looking to pull everything into Workfront. However, one of the key pieces of their Agile Methodology is the idea of the burndown with the focus being on Remaining Hours, instead of the Completed Hours like WF uses. Has anyone else had any luck coming up with a way to show remaining hours, or a work around of some sort to mimic what would be remaining? I'd love any advice on using Agile in Workfront! Thank you, Dagan Peterson Mountain West Farm Bureau MIC
Topics

Topics help categorize Community content and increase your ability to discover relevant content.

8 Replies

Avatar

Level 10
Yeah I asked them about Remaining Hours a couple of years ago to no avail. So the workaround we began to use is adjusting the Planned Hours. So if a Task started as 40 hours, but 20 hours into you realize there's another 30 hours left, you change the Planned Hours to 50. This will help adjust your burndown chart. I know it's not exactly the same, but it may get you what you need and it's a constraint of the current tool. Unless DDH has same fancy product that'll address this. Vic Alejandro, PMP, CSM | IT | Sr. IT Project Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

Avatar

Level 2
Okay that makes sense! Just out of curiosity, do you ever run into any issues with showing original estimated planned hours vs new planned hours if you have to change it? I know another, sort of off topic, discussion we've had as a PMO has to do with trying to estimate work more accurately. I'm thinking there may be a time when we want to look back at what we originally estimated and what it turned out to be so we can evaluate our estimating skills. That's not really an agile thing as much as it is just a people thing. Thanks for your tip! Dagan Peterson Mountain West Farm Bureau MIC

Avatar

Level 10
Yeah for Agile tasks we haven't been too concerned with capturing the original estimates. I guess because they're "agile" and we typically don't have all the requirements when we get the task (we get an idea and start building stuff, show the user, make changes and repeat). Teams do keep track of their velocity though, so they keep an eye on it in that sense and probably informally try to improve their estimates as they learn. But for regular projects, we keep track of the original overall project estimates by using the Baselines in Workfront. This is only project level though. We haven't gotten sophisticated enough to compare baselines at the task level yet. We also Export the Business Case from Workfront at the initial creation of the plan and then each time we do a Change Request to adjust scope, schedule, or budget. So currently in our project management maturity, we're working on getting PM's to create and maintain solid project plans in WF. They've improved since we got WF, but we're just beginning to hold them accountable to overall project estimates (and improve from there). They still might get some information from the Planned Hours vs Actual Hours as people may not always keep their Planned Hours completely current �� . So if they are way off on their project estimates, they can take a peak at some trouble areas in the tasks. Vic Alejandro, PMP, CSM | IT Program Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

Avatar

Level 10
Thanks for pointing this one out, Vic, Sounds like your just-update-the-planned-hours-as-needed Workaround is sufficient, and I'm a big fan of Baselines, too, but I was mulling over what a Better Way would look like (if there even is one). Using an example of a Task with 40 Planned Hours originally, and 15 Actual Hours done so far, but the realization that it's likely still going to take 35 hours to finish from this point (so an extra 10 hours above the 40, which is 50 in total): · At the Task Level, add a numeric text parm called "Additional Hours" (e.g. 10), a numeric calculated parm called "Estimate At Completion" (e.g. Planned Hours + Additional Hours = 50), and a numeric calculated parm called "Estimated Hours Remaining" (e.g. Estimate At Completion – Actual hours = 45), then add a Task view to show all of these in a grid for ease of data entry and gut checking (e.g. if Estimate At Completion > Planned Hours, show in Yellow, etc.) and as many groovy charts as you wish (since the data is persisted) · Same as above, but with additional numeric calculated parms for some interesting stats for the grids and charts such as "Estimate Over Planned As Percent", "Additional Over Planned As Percent", etc. · Similar to above, but – with the convention of always using having a default baseline in hand –replacing all the Planned Hours with the Default Baseline Task's Planned Hours instead, conceptually driving from the last approved Baseline (for stability) vs the Planned Hours (lest someone have changed them "inadvertently") As an aside, I the first two concepts in the (competing) software company that I owned before I changed jerseys and partnered with Workfront. You've reminded me how powerful they were! Regards, Doug

Avatar

Level 10
Nice! Yeah I also thought about simply adding a field to a custom form called Remaining Hours. However the downside is it's just informational and doesn't drive anything. You kind of solve that here. But the other downside I had would be I'd have to attach the form to every task, which started getting into messy territory that I'm sure our PM's wouldn't follow �� . When you say a "parm" are you referring to a custom form field. I know it's short for Paramater, but are you saying the field is part of a custom form or something we can kinda code within a Workfront screen? Vic Alejandro, PMP, CSM | IT Program Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

Avatar

Level 10
Thanks Vic, Yes, parm = custom parameter, which I agree could get busy. So, on that note, Now that Workfront allows multiple custom forms, whenI'm working our a proof of concept on something like this, I usually keep it all contained to a single form (easily "dropped" later if I want to back out). In this case, though, I also see the need to persist the calcs (so you can chart them), which by extension, means you have to be diligent in ensuring that every task of interest always has that custom form attached to it. Traditionally, most people do that manually with an exception report to spot new (missing-the-form) items and then bulk update them to attach the custom form. I, on the other hand, cheat, of course, and use our UberCalc solution to ensure every Task has the form automatically. Regards, Doug

Avatar

Level 10
OK Cool. Thanks. Actually, this is kind of cool too for some that may not know, but you can add the field in question to a View and it'll be blank initially of course. But once you enter data in the field the custom form is automatically attached. So then you can just add it to those tasks that you want to include that field. Or at least it's an easy way to see which don't have it. "Good talk Rusty" Vic Alejandro, PMP, CSM | IT Program Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

Avatar

Level 10
Good talk indeed, Vic! I happen to be working with a client today and by total coincidence, they brought up this exact need, so I called up this thread and we've just gone through it together. It sounds like a winner to them, and they are in the luxurious position of already having a common form (thanks to Templates and diligent processes) on every Task, so we are going to do the Proof of Concept right onto that existing form. As a bonus, since we're I'm also going to add a numeric calculated parameter called Original Planned Hours, with this formula: IF(ISBLANK(Original Planned Hours),Planned Hours,Original Planned Hours) What this subtle gem does is to capture (forever) whatever the Planned Hours on every Task to which its custom form is already attached (e.g. up to "right now", in my client's case), and whatever the initial Planned Hours were initially entered on any Task to which the form is attached (e.g. from the Template, "going forward"). That last one actually could solve this "https://community.workfront.com/discussions/community-home/digestviewer/viewthread?MessageKey=85047ac7-7e77-4c48-ace6-5998c00484b5&CommunityKey=aaafaff0-5e4e-4e38-8903-f1f990935567&tab=digestviewer#bm85047ac7-7e77-4c48-ace6-5998c00484b5#bm8">other thread too, where folks were wondering how to track where a Project's Planned Completion Date has (silently) moved. I'll go put the answer there. Regards, Doug P.S. to get this formula to work, you'll need to add the parameter to the form with no formula, save (so Workfront "knows" that parameter exists), THEN add the formula (since it refers to that parameter) and save and close P.P.S. for existing Tasks, remember to also Recalculate Custom Parameters to inject the initial values Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads