Pre-Planning of tasks from the technical team for the next release cycle
I am trying the following out right now and I would like hear you comments/inputs about that idea and feel free to discuss.
The idea is to have a list of deliverables that make sense from the view of the Frontend Team to schedule for the next release. During the next planning we have a better overview what makes sense to do and then pull ,in the discussion with the product leads, from this list and take a look what makes sense in that release. By example basic technical changes, refactoring to remove technical debt, unifying implementations over the code base, quick wins (as we just did something there), Focus areas (By example time boxed fixing of responsive issues for 4 days), etc. . This should improve the situation to get such things into the pipeline while having a better overview during resource planning. Also to improve the situation that technical changes/debt are not forgotten for a longer period in time.
- Everyone can contribute deliverables or topics (for time boxing) and suggest them (it needs to be a deliverable). If you want to add an issue , please write a comment with it in this issue : gitlab-org/gitlab-ce#32519 and explain why this makes sense to schedule it in a sentence
- I will try to gather also an impact value (ex. if we fix it then our tests will run 20% faster and will be more stable, or nice to have and saves some lines) and the potential problems (for risk assesment). Based on these inputs, available resources i will suggest during future release planning stuff that would make sense to be done during this iteration.
- By example if we exchange a basic library this should be timed so that at the beginning of a new iteration its already read, the change is already in and most of the people work based on that master version, to reach the biggest potential of dog fooding while doing such changes. This should potentially reduce risk of bugs
- Issue Time Boxing has the efficiency bonus that if a person works 5 days in the same 3 files and fixes all problems (from big to small) this should be much faster then doing all tickets over a longer time period