kylin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adunuthula, Seshu" <>
Subject Re: Setting up Agile Processes for Kylin
Date Fri, 09 Jan 2015 14:11:44 GMT

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.

Seshu Adunuthula

On 1/9/15, 5:38 AM, "Luke Han" <> 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
>by Apache JIRA (migrating from github now).
>    There are daily stand up and other events to drive development
>     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
>     Since Apache requires most of activities through mailing list, it
>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.
>2015-01-09 3:15 GMT+08:00 Ted Dunning <>:
>> On Thu, Jan 8, 2015 at 10:33 AM, Adunuthula, Seshu
>> 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.

View raw message