[kforge-dev] Proposal: online KForge planning game

[Rufus Pollock]

Both in my capacity as 'customer' and my role as 'developer' I concur 
entirely with these suggestions and would be very happy to follow this 
plan in relation to the current iteratoin. Further comments follow below.

~rufus

John Bywater wrote:
> Rufus and I have talked about making the KForge project more open, and 
> to this end we wanted to attempt to do the planning game online. For the 
> last 15 iterations, it's always been face-to-face.
> 
> The general concerns of distributed agile software development are 
> described in a few places, for example in [1], but the solutions are 
> experimental.
> 
> In short, we can start to make "distributed agile" work by tailoring the 
> agile approach to our distributed context.
> 
> Particularly I suggest we:
> 
> 1. Invest in bi-lateral remote communication - all the usual suspects 
> (IRC, IM, VoIP, etc.) can be used to increase communication capabilities 
> between individuals, and thereby to avoid "death by distance". Attempt 
> to get good at distributed pair programming....
> 
> 2. Generate and publish the dates and serial numbers of iterations well 
> into the future, with a notice that a planning game will be held at the 
> start of each iteration, and publish a description of the planning game.

This is an important point and one you have made before. My suggestion 
would be to have month-long iterations with the planning game fixed to 
start on a regular day close to the start of that month (e.g. the first 
thursday of every month).

> 3. Split iteration planning game into four distinct parts:
> 
> (i) at any time during the project, the customer writes and publishes 
> user stories to an issue tracker, the customer estimates and publishes 
> an estimate of the benefit of each story to the issue tracker, the 
> customer makes sure there is always a good "head" of unimplemented stories;

Implementation detail: we are currently using trac for project managment 
and suggest that all user stories (use cases?) be entered as 
enhancements in the tracker and that the value/benefit be set by the 
priority (1=lowest, 5=highest)

Aside: i am not sure what the semantic difference between severity and 
priority is for trac tickets (severity seems oriented to bugs while 
priority seems oriented to tasks and improvements0

> (ii) at the start of each iteration, the customer chooses as many user 
> stories as completed on average during the last few iterations, marks 
> these within the issue tracker (e.g. against a Trac milestone), when 
> done the customer notifies the mailing list that this descision has been 
> made;
> 
> AND THEN, EITHER
> 
> (iii) when the selected story list notification arrives at the 
> developers inbox, the developers continue with the iteration by 
> implementing the user stories until available working time expires.
> 
> OR (if more analysis and planning accuracy is desired for the price of 
> less implementation time, or if there are more than a very small number 
> of developers)
> 
> (iii) when the selected story list notification arrives at the 
> developers inbox, the developers self-select stories (somehow), and then 
> break the stories roughly down into tasks, estimate each task, add task 
> estimates up to create story estimates, and create a total estimate for 
> the selected story list;

Implementation detail: Do costs go on each story or on the milestone? If 
so how we will enter these costs: we could (ab)use the severity option 
on trac enhancements for this purpose.

> (iv) if the total task-based estimate differs greatly from the available 
> time, the customer bumps or pulls stories, perhaps pulling some extra 
> task-breakdown and task-estimation work, until the plan is thought to 
> fit the resource;
> 
> (v) when the iteration plan is agreed by everybody, the developers 
> publish their task breakdown on the issue tracker against the milestone, 
> notify the mailing list that their planned tasks are pubished, and 
> continue with the iteration by implementing the user stories task by 
> task until available working time expires.
> 
> 4. As the iteration continues, the developers track the completion of 
> their own tasks, and notify the mailing list and the customer when user 
> stories are completed, then the customer either provides feedback or 
> accepts the user story implementation, but the customer tracks 
> completion of the user stories. Developers and customers communicate as 
> much as they can, and sometimes pay each other visits.
> 
> 5. Regular method retrospectives to provide a place for discussion of 
> the process. Perhaps we could post a standard invitation at the end of 
> each iteration to provide feedback on the development process as it was 
> during the last iteration?

Would it perhaps make sense to run this at the start of the *next* 
iteration and integrate it with that iteration's planning game

> 6. (Optional extra) We could maintain a release plan by saying that 
> three iterations make a release, using the latest average 
> stories-per-iteration count to estimate how many user stories will be 
> implemented in each release, and then listing out (in order of estimated 
> value) the unimplemented user stories against each release. The customer 
> could update the release plan each release, or every three iterations.

Think this is a good idea and would agree with release = 3 iterations. 
Suggest update release plan every 3 iterations.

> Perhaps we could try the above routine for this iteration?
> 
> With my best wishes,
> 
> John.
> 
> [1] http://www.agilealliance.com/articles/steindlchristophdistr
> 
> 
> _______________________________________________
> kforge-dev mailing list
> kforge-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/kforge-dev