Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Schedule Management
Agile & MS Project :
Network:31



How much do you think we need to master in Microsoft project in this new Agile world, it seems to be obsolete to have lengthy schedules, as sprint completes in 2 weeks. Please guide me
Sort By:
Page: 1 2 <prev
Network:136



Apr 15, 2019 6:45 PM
Replying to Patrick Dicey
...
I would consider myself an MS Project "expert" and while I am a certified Professional Scrum Master (PSM), I am very beginner when it comes to agile, with limited professional experience.

I would be interested to gain more experience with agile. I foresee using MS Project in an agile environment in a manner such as this, but would be curious to hear how others have been using it, or why they feel it's unnecessary to use a scheduling tool. I know there are existing PMI webinars on scheduling in an agile environment you can lookup as well:
-Create a "parking lot" of the Product Backlog Items near bottom of the schedule.
-Create sprints as "planning packages" with their timebox durations and link them to milestones such as release dates. This way you can see sprint durations and quantities leading to major milestones. Dependencies may exist at the sprint level.
-Per scrum, pull PBIs up into the sprint as it becomes time. Perhaps they can be notionally assigned to the next few sprints if desired, to see/predict functionality to be phased in over time. As other's have said, this will be very fluid. At the end/start of each sprint items will be pushed/pulled out of and into the current sprint which will affect subsequent sprints. This is fairly quick and easy to make these adjustments in project within the summary tasks and modifications of dependencies.
-If you have multiple scrum teams (scrum of scrums) you can have multiple sprints running in parallel driving functionality milestones/releases/deliverables.
-Other external (schedule visibility) tasks case be added as needed that affect development such as: hiring of specific skillsets, adding of infrastructure, third party dependencies, signing of contracts, etc. In the three dimensional world these dependencies do exist and having them in the schedule will help ensure they are managed accordingly.

As I said - I am an agile/Scrum beginner but these are my thoughts. I really do like MS Project and integrated schedules as an organization tool, if nothing else or more than that.
Patrick,
I've worked in environments where they tried to manage Agile projects with waterfall and excel and it becomes a maintenance nightmare. You end up becoming a slave to the tool just to keep the dates and resourcing up-to-date and that's hoping you're not expecting your resources to manage their tasks in those tools as well. From a Product, Feature, and Release perspective you could manage those via timeline without a ton of trouble but for me, I've always found it easier to manage those aspects in the tool where the work is being done as well.

If you're a Microsoft guy then look into MS Planner (basic, like Trello) and Team Foundation Server to run your agile projects from a day-to-day or sprint-to-sprint standpoint. Understanding velocity and flow will really help you communicate timelines if that is a requirement.
Network:193



Apr 15, 2019 6:45 PM
Replying to Patrick Dicey
...
I would consider myself an MS Project "expert" and while I am a certified Professional Scrum Master (PSM), I am very beginner when it comes to agile, with limited professional experience.

I would be interested to gain more experience with agile. I foresee using MS Project in an agile environment in a manner such as this, but would be curious to hear how others have been using it, or why they feel it's unnecessary to use a scheduling tool. I know there are existing PMI webinars on scheduling in an agile environment you can lookup as well:
-Create a "parking lot" of the Product Backlog Items near bottom of the schedule.
-Create sprints as "planning packages" with their timebox durations and link them to milestones such as release dates. This way you can see sprint durations and quantities leading to major milestones. Dependencies may exist at the sprint level.
-Per scrum, pull PBIs up into the sprint as it becomes time. Perhaps they can be notionally assigned to the next few sprints if desired, to see/predict functionality to be phased in over time. As other's have said, this will be very fluid. At the end/start of each sprint items will be pushed/pulled out of and into the current sprint which will affect subsequent sprints. This is fairly quick and easy to make these adjustments in project within the summary tasks and modifications of dependencies.
-If you have multiple scrum teams (scrum of scrums) you can have multiple sprints running in parallel driving functionality milestones/releases/deliverables.
-Other external (schedule visibility) tasks case be added as needed that affect development such as: hiring of specific skillsets, adding of infrastructure, third party dependencies, signing of contracts, etc. In the three dimensional world these dependencies do exist and having them in the schedule will help ensure they are managed accordingly.

As I said - I am an agile/Scrum beginner but these are my thoughts. I really do like MS Project and integrated schedules as an organization tool, if nothing else or more than that.
Thanks for the feedback John. My explanation of a complex process was probably not great but I would not call what I described waterfall methodology. It's not an end to end plan, but it does allow you to forecast. In DOD realm I've seen a similar approach implemented successfully on very large development programs; they call it a 'rolling wave' approach but I see it very adaptable and similar to agile as well - just with different terminology.

I have never used MS Planner - I will take a look at that. I have used TFS for requirements breakdown purposes but did not see how it can provide the same visual/organizational tool with forecasting capabilities as I described, but I am sure there are TFS capabilities and ways to adapt the tool I have not seen first hand.

Thanks again for your input.
Page: 1 2 <prev  

Please login or join to reply

Content ID:
ADVERTISEMENTS

Egotism is the anesthetic that dulls the pain of stupidity.

- Frank Leahy

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events