23

TL;DR What is industry standard of how many projects one PM should manage at the same time? There's no such thing; individual projects vary greatly in the level of effort required to manage the project properly. In addition, each project management framework varies in how much overhead is involved. Therefore, the correct question is "How many hours per ...


9

In our company we also face similar problem and I would agree to the post above that kanban is a good choice. Kanban board provides all the necesarry visibility and clarity for team, also we do stan up meetings for quick overview. During planning phase we take parts - if the planning is for first project, we invite only the members that are related. In such ...


8

So, it looks like, you have two problems: Clear priorities. Delivering various projects in parallel. First one can be addressed by creating a clear list of all features (not tasks!) from different projects you work on -- so called Backlog. And this Backlog is common for all projects. And you set policy that you work on this list from top to bottom no ...


7

Although I cannot fault CodeGnome's answer above, I feel like the question has not been fully answered and we circle back once again to the flexibility of the names Agile, Scrum, Kanban etc. Maxim, you have several component parts to your problem which; all of which we face in our department. Multiple Project Requirements (Backlog) Project Backlogs ...


6

The key phrases to remember with Kanban are 'visualise the backlog' and 'limit work in progress'. For this reason I think Kanban is best managed using a single board. Otherwise people find it hard to visualise the total amount of work that needs to be done or that is currently in progress. Multiple boards also make it harder to set hard limits on the total ...


6

I think this is totally possible as you need to agree on one and the most important rule. When you plan sprint backlog, you close it and there is no place for new "unexpected" work items. Because you will be forced to deliver value on each of the ongoing projects, in any other case you will fail not one project but all together. Also, it is important that ...


6

From a PM point of view it is two separate projects. If the same developers work on both Android and iOS client, you could however run it as one project. You could achieve a reasonable feature alignment, by having two versions of the user stories (iOS / Android) and prioritize them one after the other. However, if it's two different teams you can't and ...


5

We use Trello in a very similar setting and have indeed encountered the same issue. Our current approach to resolve it is to divide the planning into two phases: First, we distribute our velocity over the projects, to plan how much attention we give to each project in the next sprint. Everyone does this for himself, since different people participate in ...


5

Do your projects sequentially, one at a time. Period. And how do you prevent the fact that other projects/clients won't be waiting for a month... Think this one through: say you have three projects to do, and each one will take four weeks (with the entire team working on it). Further assume you wouldn't lose any time switching between them. If you do ...


5

I hope theres not too much redundancy to other answers, but I wanted to go in to some details about tools you might use in agile team with several projects. What we do (about 6 developers, on 2 bigger and upto 4 smaller projects at the same time) is as well combining tools from different technologies. We write specifications based on user stories, which we ...


5

There shouldn't be any difference in the user stories or acceptance tasks\tests because both are explaining functionality, which will be the same for both apps. Having said that, it's recommended to create tasks for each platform (even if they are the same)as it will be easier to track the progress for each version because of the following reasons: 1.Time ...


5

TL;DR My research is covering on how we could have 1 SCRUM board for 1 Team that works on multiple projects simultaneously. SCRUM methodology is not just for working on 1 project, it tells us what kind of work we have to complete and how we are going to complete it (and in what timespan). [Sic transit throughout.] Working on multiple projects ...


5

You can't compare efforts between marketing and accounting; accounting is non-competitive. I suspect it is an error to try to compare efforts which are dissimilar. The problem set before you is difficult and potentially wicked. On the other hand the only option you can rule out is to do nothing. I suspect that if I were in your shoes, I'd ask the teams to ...


5

That sounds like the perfect case for a board. I'm explicitly not saying scrum or kanban board, but a board. To visualize all the different modules as cards with their current status and additional information, maybe due dates etc. Personally, I like Trello a lot, it's online, the basic version is completely free of charge and you can create your board and ...


5

TL;DR In most cases, you should only have one project per product. The desire to split a single product into multiple projects is usually a sign that inter-team collaboration and iterative integration have become a central bottleneck for your process. I provide additional analysis and recommendations below. One Product ➡️ One Project ➡️ One Integrated ...


4

I completely support Mark C. Wallace on his suggestions. Once you have the goals set though, you can't just let them go on "auto-pilot". If you set a goal for the next quarter, and then you don't check in with your teams until the end of the quarter, odds are those goals are going to be missed. It's just basic human nature and why, despite it being field ...


4

If you stick to a strict interpretation of Scrum, 1 story board = 1 team = 1 project. Could you use multiple story boards? Sure, but purists would probably argue you're not doing Scrum anymore. Are you doing Agile-Scrum? Yes, possibly... If the solution you choose (one or many story boards) is desired by the team(s) and improves their ability to deliver ...


4

I think Kanban may work best in your environment. And with some people being remote, you're almost forced to use an online Kanban board. I'll try to address the two issues you raise one by one. Global View You can maintain a Global View of the multiple projects by: Having all projects on the same board, and indicate with a color what project the task ...


4

It sounds like you're operating in chaos, with purposeful loose change control. I am not sure a tool or method is the right solution but rather resetting expectations on what you are able to forecast and promise by way of delivery. If you are in constant flux in terms of your timeline and cost accrual against specific projects, there is no way you can ...


4

Generally, the question I would ask is: "What benefit do you gain from splitting them?" The risk in splitting them is that your prioritization loses focus on end value and, more broadly, that you could get a lot done, but not meet the success criteria of the project because some teams excel while others struggle and you erode focus on that. Many times I ...


4

[...] working in a small SCRUM team (capacity ~ 3 FTE) that must deal with multiple projects in various stages Scrum works best for one team working on one project. If you have things coming your way that can't be planned in advance, then you will need to put aside a capacity buffer for those things so that the stable part of your sprint still has a meaning ...


3

I recommend determining what you are trying to measure first, and then look at how you are organizing your project data. The answer is very likely that you'll need different groupings for different purposes -- financial forecasting, resource planning, etc. I've found people quickly tire of micro-categorizing and you'll discover everything in the "General" ...


3

In order of your questions.. How do you keep the iOS and Android developers on the same page? They are building different clients for the same product. I would treat this a single project. This is a scenario where you have to have a bit of union & separation at the same time Both iOS & Android Developers should belong to one scrum team ( Other ...


3

For anyone encountering this question, this is how I do it: Create an overall project file like allmyprojects.tjp Include all needed tji files with include "path-to-tji" {taskprefix sub1} By specifying taskprefix you can have the tasks with the same ID in subprojects. Schedule allmyprojects.tjp In allmyprojects.tjp you can specify reports just as in the ...


3

Welcome to the community! As Vadim mentioned in his comment, your question is a little complex, so I'm going to try and break it down into bitesize chunks. We use it more as a todo list than a real project management system. First off, strictly speaking, Kanban is not a project management system or methodology. Kanban is a framework, or a set of ...


3

You need to build an integrated master schedule. You need to pull in all your separate projects' schedules into one schedule and link them. You can link the work packages from different projects directly or you can create major and minor milestones within a sub project and link those, or a combination. Based on Mark's comments below, I do need to add as ...


3

Scrum as a process is a good way of delivering a project which will take several sprints to deliver. It is also very fashionable. However it is not such a good process for delivering bugfixes and small change requests with near-zero lead times. Using a Kanban board on JIRA would be the ideal solution, as Daniel mentions above. Sometimes our estimation is ...


3

The foundation for managing "highest priority" work in multi-projects is actually order, not priority. There is a saying that goes "When everything is urgent, nothing is". On the same train of thought, when everything is "priority one", nothing is. What you need, is someone with decision power that can create that order for you. ...


2

As RubberDuck noted, kanban seems like a pretty good place to start in terms of process. Just constructing the board and flow will probably give you and the team a lot of insight into the amount and nature of the "chaos", and if you can use it for a few weeks, gain a lot more insight into bottlenecks, loops, blockers, etc. Just be sure to use columns or a ...


2

I would recommend you make separate boards for the independent projects unless the same team is working on all the parts simultaneously, which doesn't make much sense to me based on your short post. If you are using the same board, then color code the different parts. If you are using an electronic board, then you can use tags or labels. Your swim-lanes ...


Only top voted, non community-wiki answers of a minimum length are eligible