How to plan a very big project as a newbie

Question

Hello =)

I'm working on a very big project as a student assistant in germany. The project contains over 100 work packages and every work package takes between 1-12month to finish. We work together as a consortium of multiple universities. I can not tell how many people are involved in the project, but i guess around 80-100 employees. The project lasts for the next 5years.

My boss asked me to get used to Jira and use it as a projectmanagementool for our project.  (Yes thats a big task, but I really want to find a solution!) Until now I watched some Tutorials and tried to get use to the functions of Jira.

I would like to tell you about my idea how to solve this problem and ask you to tell me your thoughts related to my plan:

* Due to the fact that there are probably something between 5000-50000 issues in total , I want to create one Scrum board for every work package (which means I create around 100 Scrum Boards).
* I create a page on our confluence wiki with the following instructions: The leader of every work package has to create (inside their own bord) all the issues which are necessary to finish their work package. I guess something between 50-500 Issues per Package. (I would give the rights to work on and edit the board to the respective work-package-leader)

In my opinion every work-package-leader is able to control their progress and start sprints.

Do you think that this is the right way to implement the plan? Any recommendations or something? I would be really thankful for any advice!

Thank you so much in advance!

unknown · Answer

Hi @Philipp Dewies,

Please question away. :)

1) Visibility of issue dependencies in JIRA are displayed on the issue itself. If you have 2 or more work packages that rely on each other and the issues are on separate boards entirely, when it comes to choosing issues to work on you will waste time trying to track dependencies since you will be constantly flipping between the boards or issue dependencies to find out when an issue can start.

I'm not saying you cannot do it this way, just thinking about the big picture of your huge project. I would not want to waste time waiting for issues to be complete before working on your own.

2) Sprints can vary in size, the important thing is to be consistent in your time frame for sprints, any changes to the time frame of a future sprint need to be communicated up front and to all involved. I have worked on projects where sprints have ranged from 8 weeks to 1 week.

When choosing your time frame make sure the decision is guided by the products you are creating, if the MVP is complex allow for more time.

You can break up your work packages into smaller bites and I highly suggest you do this, allowing a project to continuously run for a year before the work package is ready is susceptible to greater risks, as well becoming slow to change when the project's business values change.

But when everybody is copying the master board I will have a lot of boards again and so there will be those "visibility difficulties". I think I just get you wrong here.

^

Since your project is so large you are bound to have a lot of issues to work on, regardless of the sprint length and the size of the project team. If you create a master board with all issues within a sprint you have greater visibility over the entire project. JIRA allows you filter the results on board, though as you originally stated you are working with quite a few other parties, this would require a full time JIRA admin to respond to board requests and troubleshooting.

Instead, once another person copies your original board they are able to edit the board's filter without changing your own. If their issues have been tagged by the vendor, I would use Components in this use case, they will see the same sprint that you have set up though only their issues with the Component tagged on them would display. I have worked on a couple of huge projects before and this is the easiest way to manage the project and maintain control of the project's progress.

Let me know your thoughts :)

Philipp Dewies · Answer

Hi @[deleted],

thank you for your advice! I have a few questions (probably beginner questions, I'm sorry for that) regarding your answer:

If you have dependencies between work packages then splitting those work packages up into different boards is going to make visibility difficult. My advice would be to create a master scrum board with set sprints for all work within sprint 1, sprint 2, etc. To reduce information overload, set up quick filters so you can easily find what you are looking for within the one board.

1) So what do you mean with it makes "visibility difficult"?

2) Do you mean with "set sprints" that I have to create a sprint for every work package? I thought I shouldn't use sprints which last longer than 2 weeks. (work packages take up to one year to finish) It would be great if you could explain that to me how it works.

Get the leader/s of every work package to copy the master scrum board and modify the filter to suit their needs. At least then you have a starting point for users to go from.

But when everybody is copying the master board I will have a lot of boards again and so there will be those "visibility diffculties". I think I just get you wrong here.

Thank you so much!

unknown · Answer

Hi @Philipp Dewies,

My thoughts are below;

I would like to tell you about my idea how to solve this problem and ask you to tell me your thoughts related to my plan:

* Due to the fact that there are probably something between 5000-50000 issues in total , I want to create one Scrum board for every work package (which means I create around 100 Scrum Boards).

If you have dependencies between work packages then splitting those work packages up into different boards is going to make visibility difficult. My advice would be to create a master scrum board with set sprints for all work within sprint 1, sprint 2, etc. To reduce information overload, set up quick filters so you can easily find what you are looking for within the one board.

Get the leader/s of every work package to copy the master scrum board and modify the filter to suit their needs. At least then you have a starting point for users to go from.

* I create a page on our confluence wiki with the following instructions: The leader of every work package has to create (inside their own bord) all the issues which are necessary to finish their work package. I guess something between 50-500 Issues per Package. (I would give the rights to work on and edit the board to the respective work-package-leader)

Again, dependencies. If you have integration of work or depend on another party then creating your own work packages in isolation will only end with everyone blaming others for not taking their work packages into account. You need to get leaders together in repetitive backlog refinement meetings between sprints to plan the next sprint. This will help you maintain velocity and reduce wasted effort.

I agree with you though, every leader should create their own work packages, just remember to refine those work packages with everyone else. Sharing information and the project's direction will help to guide everyone else.

If you want to speak more about Project Management & JIRA offline let me know.

Hope this helps