Robert PoddarProject Manager| Identiv Private LimitedChennai, Tamil Nadu, India
Hi,
I am preparing a Gantt chart project plan for a pure Agile based Software development. I am confused as to how should i go about preparing the plan and tracking the same. How do you also do resource levelling, since in my case, we have a single team that are working on 2-3 product releases that should go to market at the same time.
Note:
1. Currently, we are not doing a backlog scrub of all tickets that are supposed to be in the release. Upfront we will not know how many points will it take to complete the release.
2. When the PO indicates that a particular ticket needs to be part of the release, the respective Tech Lead will go and update the estimate effort of the JIRA ticket. The ticket is added into the current active Sprint. If it doesn't get done in the current Sprint, then it will automatically move to the next Sprint, when the current Sprint is closed.
Robert PoddarProject Manager| Identiv Private LimitedChennai, Tamil Nadu, India
Hi Kiron,
In my case, we have a single team working in parallel on both the product releases.. the developer will work on product1 ticket and once the implementation completes, he moves the ticket to QA and then moves onto implementing product2 ticket..
We track the status of tickets for both the products in the same Sprint.
From project plan perspective, how does one do the planning? From the backlog the PO decides which tickets needs to be addressed in the Sprint and the team indicates the Sprint duration and also estimates each ticket.
i can visualise that the project plan will be populated only for the 1st Sprint.
When the team moves to the 2nd Sprint and so on, then the project plan will be populated.
Is my understanding correct with respect to project planning?
So, there isn't any baselining since we don't indicate which tickets will be in which Sprint.. how do you track the progress of the project, if it isn't baselined?
I'm not a fan of the statement the "PO decides which tickets needs to be addressed in the Sprint". The PO needs to ensure the team understands the priorities, but the team decides what they can actually deliver within a sprint.
Tracking the progress against a release is based on understanding the size of the release backlog (i.e. what is left to be done) as a function of the delivery velocity of the team. That will help you know if it will take fewer or more sprints to get to done than what had been originally estimated and approved.
Tools like JIRA provide reports which can provide you with the "cone of uncertainty" around a forecast release date.
Kiron Saving Changes...
Vivek BhatiaPrincipal| The Bhatia GroupOakland, Ca, United States
My last client had the tech teams use Agile, but the ePMO & finance insisted upon project plans. The two are in conflict.
My resolution was to put A) all actual work, ie user stories into TFS (now Visual Studio Team Services, pretty cool). These had the tasks & bugs assigned to it. B) Epics & Features were the bottom 2 layers of the WBS in the traditional project plan.
If you must track actual hours in project, like I had to, then create a final layer with "Iteration 2 work", "Iteration 3 work", but only for those iterations where the feature is being worked upon. Don't always start at 1.
Even in Agile, you can target how many iterations it'll take to complete a feature. It'll change, but that's true even in traditional project plans, and why project managers aren't just secretaries who administer a written-in-stone plan created at the beginning of the project.
That way finance & ePMO got their pretty gantt charts with finger-in-the-wind estimates of feature completion, and engineers have the freedom to complete the work in the appropriate fashion.
...
1 reply by Robert Poddar
Aug 02, 2018 7:45 AM
Robert Poddar
...
Hi Vivek
Thanks for your inputs. Will it be possible to share a template of what you describe?
thanks
Robert.
Saving Changes...
Robert PoddarProject Manager| Identiv Private LimitedChennai, Tamil Nadu, India
Hi Kiron,
We have a single team that is working on both products at the same time. The tickets related to both the products are tracked in the same Sprint. The developer will work on product1 ticket and once he/she has completed the implementation, the ticket is moved to QA.. the developer then moves onto product2's ticket..
Just to understand with regard to project planning. At the beginning of the project, since we don't know in which Sprint the ticket will be addressed, i assume that the plan will only be populated for the 1st Sprint. Once Sprint1 is completed and the team moves onto Sprint2, then the plan will be updated.. is this understanding correct?
Is there a concept of Baseline in Agile development? How does one track the progress of the project?
thanks a lot for your inputs/help..
Robert.
...
1 reply by Robert Poddar
Jul 31, 2018 12:04 PM
Robert Poddar
...
Hi Kiron,
Sorry, i didn't notice that my earlier statement was posted.. kindly ignore this one..
Sorry for the inconvenience..
regards
Robert.
Saving Changes...
Robert PoddarProject Manager| Identiv Private LimitedChennai, Tamil Nadu, India
Jul 31, 2018 12:02 PM
Replying to Robert Poddar
...
Hi Kiron,
We have a single team that is working on both products at the same time. The tickets related to both the products are tracked in the same Sprint. The developer will work on product1 ticket and once he/she has completed the implementation, the ticket is moved to QA.. the developer then moves onto product2's ticket..
Just to understand with regard to project planning. At the beginning of the project, since we don't know in which Sprint the ticket will be addressed, i assume that the plan will only be populated for the 1st Sprint. Once Sprint1 is completed and the team moves onto Sprint2, then the plan will be updated.. is this understanding correct?
Is there a concept of Baseline in Agile development? How does one track the progress of the project?
thanks a lot for your inputs/help..
Robert.
Hi Kiron,
Sorry, i didn't notice that my earlier statement was posted.. kindly ignore this one..
Sorry for the inconvenience..
regards
Robert. Saving Changes...
Robert PoddarProject Manager| Identiv Private LimitedChennai, Tamil Nadu, India
Jul 31, 2018 11:00 AM
Replying to Vivek Bhatia
...
My last client had the tech teams use Agile, but the ePMO & finance insisted upon project plans. The two are in conflict.
My resolution was to put A) all actual work, ie user stories into TFS (now Visual Studio Team Services, pretty cool). These had the tasks & bugs assigned to it. B) Epics & Features were the bottom 2 layers of the WBS in the traditional project plan.
If you must track actual hours in project, like I had to, then create a final layer with "Iteration 2 work", "Iteration 3 work", but only for those iterations where the feature is being worked upon. Don't always start at 1.
Even in Agile, you can target how many iterations it'll take to complete a feature. It'll change, but that's true even in traditional project plans, and why project managers aren't just secretaries who administer a written-in-stone plan created at the beginning of the project.
That way finance & ePMO got their pretty gantt charts with finger-in-the-wind estimates of feature completion, and engineers have the freedom to complete the work in the appropriate fashion.
Hi Vivek
Thanks for your inputs. Will it be possible to share a template of what you describe?
thanks
Robert.
...
1 reply by Vivek Bhatia
Aug 02, 2018 10:33 AM
Vivek Bhatia
...
give me 24 hours, i'll mock something up. I'm in the middle of writing a full mock project as part of a white paper, I have the Epics/Features, but no project plan (yet). Will knock that out today.
Saving Changes...
Vivek BhatiaPrincipal| The Bhatia GroupOakland, Ca, United States
Aug 02, 2018 7:45 AM
Replying to Robert Poddar
...
Hi Vivek
Thanks for your inputs. Will it be possible to share a template of what you describe?
thanks
Robert.
give me 24 hours, i'll mock something up. I'm in the middle of writing a full mock project as part of a white paper, I have the Epics/Features, but no project plan (yet). Will knock that out today.
...
1 reply by Robert Poddar
Aug 03, 2018 5:21 AM
Robert Poddar
...
Hi Vivek,
No issues :).. thanks for the help..
Regards
Robert.
Saving Changes...
Robert PoddarProject Manager| Identiv Private LimitedChennai, Tamil Nadu, India
Aug 02, 2018 10:33 AM
Replying to Vivek Bhatia
...
give me 24 hours, i'll mock something up. I'm in the middle of writing a full mock project as part of a white paper, I have the Epics/Features, but no project plan (yet). Will knock that out today.
Hi Vivek,
No issues :).. thanks for the help..
Regards
Robert. Saving Changes...
Kavitha KoraboinaRelease Train Engineer| HomeRogers, Ar, United States
Hello Robert,
I agree with what other contributors have already mentioned. However, found online that MS Project has a version which has features usable for an Agile project, I have not used it myself so not very sure.
Regards,
Kavitha.
...
1 reply by Robert Poddar
Oct 29, 2018 7:57 AM
Robert Poddar
...
Hi Kavitha,
Thanks. I am using Smartsheet project scheduling tool. It is a cloud based tool. I will check a trial version of MS project and see how the Agile feature works in MS Project.
thanks
Robert.
Saving Changes...
Lenka PincotChief of Staff to the CEO| Project Management InstituteParis, France
Hi Robert, do you have a roadmap for the product you are supposed to develop? Product roadmap shows major features, you may phase them in time, but you will not run into conflict when scheduling more detailed user stories as you progress with your iteration planning. If that’s a product you are creating, such roadmap should be available in a rough time perspective. But then for individual sprints you use the backlog of user stories and assign them to iterations based on priorities. Would it help?
...
1 reply by Robert Poddar
Oct 29, 2018 8:03 AM
Robert Poddar
...
Hi Lenka,
Yes we do have a product roadmap, in the sense that our software needs to support a particular hardware product.
Currently, what we are doing is having the software requirements entered in JIRA. Each component team creates the JIRA ticket related to the requirement and sizes the ticket.
I pull the JIRA tickets that are meant for the release and add up all the efforts entered by the team and then through calculation come up with a rough effort in man months to complete all the requirements.
In my project plan, i will have all the tickets having the same start & finish, since the team can take up any ticket. I factor some time for bug fixes and then come up with a release date. I baseline the plan and track the same using this baseline release date. Not sure if this is the right way, but it is helping to some extent.