@mattab opened this issue on April 7th 2015

The goal of this issue is to make a sprint planning across all our repositories (plugins, components, other projects). #### Why is this important?

Currently we follow up any issues in piwik/piwik issue tracker. Problem is that we tend to forget about bug reports and suggestions made in any of the 40+ other issue trackers (such as plugins, components, side projects, log-analytics, etc.).

To build the best platform and products we simply cannot forget even one important issue. Therefore we aim to establish an effective process to manage our work across 50+ products.

The goal of this issue is to test this process at least once and see how it goes.

@mattab commented on April 7th 2015

Notes: - it will be helpful to generate accurate changelog across our repositories. see (piwik/github-changelog-generator#4)

@tsteur commented on April 28th 2015

How will this sprint planning be done? And how will it prevent those kinda issues? Eg when moving issues in a current milestone during a "sprint". In theory, a sprint is planned in the beginning of the sprint and only those issues are being worked on. In our case we do not really have a sprint that is "protected" etc. Or will this be the case now?

I'm also not sure if 4 week Sprints is really correct the best for us as we are in a maintenance mode. If we want to do that we'd probably need 1 week sprints but think something Kanban like might me more appropriate.

This issue was closed on April 1st 2016
Powered by GitHub Issue Mirror