Do project management tools like MS Project and Primavera make sense in a software team and for a software product, assuming that the team is following agile practices and uses, e.g., Scrum. Are things like product backlog, sprint backlog, etc. replacements for, e.g., work breakdown structures, Gantt charts, etc. or, ideally they should be used together for a successful project management?
MS-Project and similar project planning tools mainly focus on on the scheduling of tasks. They excel at managing scheduling dependencies between task, resources assignment, workload and duration of tasks.
In an agile context, these features are not very useful: the tasks are very dynamic, driven by the backlog, and self-organized by the team during the iteration. Working together on backlog items cannot be predicted months in advance and documenting it on the flow would be a huge overhead. The duration of iteration sets the pace and not the duration of individual tasks/activities/responsibilities. Lastly, the dependencies between tasks is fuzzy and rarely hard-sequential.
So, project schedulers are not very useful and risk to be an overhead. At best, they can be used to give some visibility on a high level product roadmap and report progress in a corporate way (if required). For larger teams they can also visualize different components in the scope (parallel and overlapping project activities in the scheduler, scheduled by hand: don’t expect a CPM here due to the fuzzy dependencies).
In an agile context, the time dimension of the project is rather straightforward: you define iterations (very often time-boxed), and the team self-organizes. No need for MS project for documenting this. The key feature that you need is to manage backlogs items. This is more efficiently done with Jira, Trello and similar tools. And these also cope better with story points, which would be very challenging to do with project schedulers ;-)
I've never used Primavera, but it appears to be similar to Microsoft Project in that it is geared toward more traditional project management approaches, rather than agile and adaptive techniques. Traditional project management techniques may be fine for projects that have fixed constraints, clear cause-and-effect relationships between changes, and have low amounts of uncertainty and ambiguity. However, agile project management techniques and their associated practices are useful in projects that have more flexibility and have more uncertainty or ambiguity that is reduced as the effort goes on.
I don't think that backlogs and roadmaps are drop-in replacements for work breakdown structures and Gantt charts. They solve similar problems in that they help to visualize the current and upcoming work, but they do so in very different ways and are best suited to different contexts. You'd choose the appropriate set of tools based on your project management methodologies, which would be based on the environment in which the project is happening.
If you have an agile software development team, I'd probably choose a more suitable tool than Project or Primavera. That doesn't mean that you can't make them work, either alone or in conjunction with other tools, but it's usually more effective to choose tools that support the process rather than forcing a tool to be used in a way that it wasn't designed for.
Microsoft Project is a powerful tool, however, it was not built for Agile teams. Thus, if you are looking to embrace this method, choosing an Agle tool might be a better solution. There are various options on the market allowing each team to find something for their needs.
For a fully Agile process, you will most likely benefit from a tool that carries specific functionality and reports. While those looking to merge Agile and traditional project management should keep their eye on hybrid project management solutions. Here is an article on the best Microsoft Project alternatives with a comparison table of main features.