Awesome. Here is what I would like to see as reports sent out to the dev list. This will improve visibility into the velocity and direction of execution. I would like Ted/Henry to give us guidance into the prioritization of the JIRA Issues.
- JIRA Issues Backlog: once every sprint one week before the sprint start. - Sprint Planning Report on the day of the sprint start. List of JIRA Issues being worked in the sprint. - Sprint Review Google Hangout. The final day of the Sprint a Google hangout with the Sprint execution report and Demos. PO and Scrum Master identified. I am guessing you are the default PO, Determine if you want to play the role of SM also? In general I have seen that playing both roles PO/SM will fail as the project scales. Regards Seshu Adunuthula On 1/9/15, 5:38 AM, "Luke Han" <[email protected]> wrote: >Thanks Seshu, > The Kylin development is running Agile way, the github issues (soon >will be Apache JIRA) contains all the backlog and working items, also >release plan. All technical relative issues, bugs, features will be >managed >by Apache JIRA (migrating from github now). > There are daily stand up and other events to drive development >internally. > > As Ted mentioned, we are trying to put technical discussion into dev >mailing list, there are already have some topics now and will come more >and >more. > > Since Apache requires most of activities through mailing list, it >will >be a little bit challenge to run Scrum exactly but we will try our best to >leverage JIRA and mailing list to run development process more agile:-) > > Thanks. > >Luke > > > >2015-01-09 3:15 GMT+08:00 Ted Dunning <[email protected]>: > >> On Thu, Jan 8, 2015 at 10:33 AM, Adunuthula, Seshu >><[email protected]> >> wrote: >> >> > Ted, >> > >> > Do you see any challenges with setting up an Agile model with Apache >> way, >> > especially when we expand with outside committers? >> > >> >> Not if the process is fairly open. >> >> Keep in mind that committers can use whatever method they like to decide >> what to work on. That could be an external scrum meeting, for instance. >> >> The technical decisions that are part of that work, however, should be >> discussed on the dev list. No technical decisions should be made >> off-list. Substantive discussions that affect those decisions can occur >> off-list, but should be reported back to the list. >>
