Using project management tools like MS Project or Primavera in an agile team

What outcomes are you looking for, and how and when will success be gauged?

Organization and collaboration tools are the mirage of the modern agile desert. You can run an entire team with Excel if the team knows what they're building, why they're building it, for whom they're building it and what quality looks like.

In theory, there would be no problem using the MS project, especially for the SPBL. But, be careful not to make plans and schedules in advance and turn your agile team into an old waterfall. Either way, I would particularly avoid it. 

To be honest I've worked with hundreds of Scrum Teams and have never seen the need for MS project and it would have been a waste of time. But if a project planning tool solves a problem for you, then go ahead and try it. You can use Scrum with projects, too. Every Sprint could be considered a project. Adopting a product mindset over a project mindset might work better for you.

Typically Scrum Teams use tools like VersionOne and Jira rather than MS Project. The Product Backlog is your plan. The Sprint Backlog will make the current Sprint's work transparent, although the work (i.e. the Product Backlog items and optionally any related tasks) may not be as granular as what would be found in a traditional WBS. Remember in Agile conversations are usually more valuable. 

Thanks for all the good answers. But, if such tools are not common in agile development teams, how should one devise a roadmap and have an estimation of when things will probably be done. Having such a roadmap I may be able to better decide about, e.g., how many new developers we should hire. How do other agile teams handle these things? It seems to me that things like product backlog and sprint backlog are useful for planning of the near future and for longer plans (e.g., one year) we may need other tools (so that, e.g., we can decide how many developers we should hire).

But, if such tools are not common in agile development teams, how should one devise a roadmap and have an estimation of when things will probably be done.

A tool like Jira, Microsoft Devops, or even Excel.

List the Product Backlog Items (PBI's).

Continuously refine the PBI's.

During sprint planning you bring some into the Sprint Backlog.

After (n) sprints you will become quite reasonable at committing to "some quantum" of "work."

estimates, no-estimates, slice thinly - use a technique that gels with your team - here is where a seasoned scrum master can help.

From that you can produce both burn-up and burn-down charts, and apparently, there is some cross-over point at which the rate you are learning, will highlight that the rate at which you are completing work, gives you an idea when your current backlog will be "done"

- with a product mindset, you're done when the product manager decides to retire the product...

But, if such tools are not common in agile development teams, how should one devise a roadmap and have an estimation of when things will probably be done.

Your roadmap is updated every time your team does a Sprint Planning event.  Estimation of when things are done is updated every Sprint Planning, Daily Scrum, Sprint Review.  That is how iterative delivery is successful.  

There are techniques that can help with forecasting.  Things such as Actionable Agile  can help you with that but it is only a forecast.  And what is the first thing you think of when you hear the word forecast?  Usually it is weather.  How reliable are weather forecasts? More reliable in short term than long term. But a long term weather forecast is usually good enough for you to decide if you want to hold an outdoor event three months from now and certainty increases as each day passes. 

Gannt charts can help with identifying dependencies but even then, they are not exact.  They change every day as work progresses and new information is found. So does a Sprint and that happens during the Daily Scrum.  Would it really be worthwhile to have a Gantt Chart for a project that is only up to a month in duration, especially when the project team is in constant communication and replanning of efforts?

Your Product Backlog shows all the work needed for a product.  Your Sprint Backlog shows all the work that is expected to be done for the duration of the fixed timeboxed Sprint.  The Daily Scrum provides a mechanism for re-planning the project every day.  The Sprint Review provides a mechanism for adjusting longer term needs for the product by updating the Product Backlog.  Sprint Retrospective provides a mechanism for the team to improve their processes and the way that they work together.  All of that occurs within a timebox of up to 1 month and then repeats itself for another of the same timebox. 

Given all of that, do you need Gantt charts, work breakdown structures, etc? 

In my opinion, MS Project makes sense for a software team and a software product. I can say this because our PM installed software like worktime (employee monitoring software) to control our working processes.

Your Product Backlog shows all the work needed for a product. 

But, do we really put all the work needed for a product in the product backlog? Consider some parts of a product, we may start developing in, e.g., a year from now (according to our estimates and resources). Do we really put it in our current product backlog? Even, if it is put, it may be a general idea, not, e.g., user stories. So, we may not have a good estimate of its size. Will it take two months or it will take a year? So, if we want to deliver it in 1.5 years from now, should we hire new developers or not?

But, do we really put all the work needed for a product in the product backlog? Consider some parts of a product, we may start developing in, e.g., a year from now (according to our estimates and resources). Do we really put it in our current product backlog?

Yes. The Scrum Guide says: "The Product Backlog is an emergent, ordered list of what is needed to improve the product."

Even, if it is put, it may be a general idea, not, e.g., user stories. So, we may not have a good estimate of its size. Will it take two months or it will take a year?

The work for a complex product is always emerging and care should be taken to establish transparency over forecasts. Only then can they be improved.

So, if we want to deliver it in 1.5 years from now, should we hire new developers or not?

The work is emergent, and might not be delivered at all. Think about your Product Goal and what you are learning now. What outcomes are you looking for, and how and when will success be gauged?

So, if we want to deliver it in 1.5 years from now, should we hire new developers or not?

Forecasting when features will be completed that far in advance will be extremely challenging with complexity, if not wasteful and irresponsible. The further away the date is, the cone of uncertainty widens. If what you are building doesn't reside in the realm of complexity then perhaps my answer would be different.

Thinking back 18 months ago, could anyone have predicted what the impact COVID has had on their company, how customers use their product and what customer's needs are, and the impact on how people work?

Even, if it is put, it may be a general idea, not, e.g., user stories. So, we may not have a good estimate of its size.

And you just explained why Product Backlog refinement is an ongoing activity.  Also, no where in the Scrum Guide are user stories mentioned. In fact the word "user" is only mentioned one time and "story" or variants do not appear at all.  The current guide doesn't mention anything about the make up of a Product Backlog Item. The most description given is when discussing refinement in the section that describes the Product Backlog. 

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

Ok. Thank you. So, if my manager asks when will you deliver these features, I should say I don't know, wait until we see what happens, is that right?

The key output of the Sprint Review is an updated Product Backlog. If your manager is a stakeholder, why not ask him or her to participate?

The Sprint Review is an opportunity to help shape forecasts about what is likely to be delivered, and when, as well as to understand the value being delivered now.

The Sprint Review is an opportunity to help shape forecasts about what is likely to be delivered, and when, as well as to understand the value being delivered now.

Extend the problem. Ok, we bring my manager into, e.g., Sprint Review. Then, the manager of the manager asks him, when will the product with such features be delivered? Then, he also ask him to join the meeting because we do not have a plan for that. Then, he also joins the meeting. Then the manager of the manager of the manager asks him when will the product with such features be delivered? And, the story continues...

It will continue for as long as people think they serve managers, and for as long as organisations look for certainty in an uncertain world. I suggest it will end once a new understanding is reached, with teams inspecting and adapting for themselves, as closely as possible to the time and place of work being carried out.

Another option is that instead of your manager asking you the question, you could have them ask the Product Owner.  After all the Product Owner is the one that is responsible for maximizing the value of the product.  They are the ones that the organization trusts to be making the correct decisions for the product.  You never state what your role is in the Scrum Team or the organization.  But all of the questions related to product features should be directed to and answered by the Product Owner. 

If you are the Product Owner and they do not accept that answer, refer them to the Scrum Master so that they may help the managers better understand how Scrum and iterative delivery works.  The Scrum Master can also educate them on how their interactions with the Scrum Team can be most beneficial or, in this case, detrimental. 

+1. Thank you