[kforge-dev] user story headings, etc.

[John Bywater]

For the next phase of KForge, we wanted to firm up the "outer loop" of 
our process.

We're following an agile approach, which in simple terms has an "inner 
loop" of basically writing tests, developing code, refactoring, and an 
"outer loop" of basically estimating stories, selecting stories, 
recording progress, and releasing versions.

outer:
http://www.extremeprogramming.org/map/project.html

inner:
http://www.extremeprogramming.org/map/iteration.html

developing:
http://www.extremeprogramming.org/map/development.html


We've got developing and the inner loop running well, but the outer loop 
hasn't been tightened much. Therefore, I propose the following two 
improvements:

1. Clarification of the purpose and form of a user story.
2. Clarification of an iteration.


++++++++++++++++++++++++++++++++++

1. Purpose and Form of User Stories:

from:
http://www.extremeprogramming.org/rules/userstories.html

"User stories should only provide enough detail to make a reasonably low 
risk estimate of how long the story will take to implement. When the 
time comes to implement the story developers will go to the customer and 
receive a detailed description of the requirements face to face."

I would like to use a spreadsheet again for the user stories, and to 
adopt these column headings:
 
- ID
- Title
- As a [ACTOR]
- I want to [ACTION]
- So that [EXPECTED RESULT]
- Est. Benefit [POINTS]
- Est. Cost [WEEKS]
- Act. Cost [DAYS]
- Notes


++++++++++++++++++++++++++++++++++

2. Clarification of an iteration:

Firstly, for the KForge project, an iteration is something that lasts 
for three weeks each month:

from:
http://www.extremeprogramming.org/rules/iterationplanning.html

"An iteration planning meeting is called at the beginning of each 
iteration to produce that iteration's plan of programming tasks. Each 
iteration is 1 to 3 weeks long. User stories are chosen for this 
iteration by the customer from the release plan in order of the most 
valuable to the customer first. Failed acceptance tests to be fixed are 
also selected. The customer selects user stories with estimates that 
total up to the project velocity from the last iteration."

This clearly calls for a release plan of estimated user stories from 
which to select, and a history of implementing user stories so that we 
have a "budget" (velocity) to size the selection for the iteration.

Stories receive their estimates in the release planning meeting:

from:
http://www.extremeprogramming.org/rules/planninggame.html

"The essence of the release planning meeting is for the development team 
to estimate each user story..."

The, in turn, clearly calls for a list of user stories to be estimated:

from:
http://www.extremeprogramming.org/rules/userstories.html

"User stories are written by the customers as things that the system 
needs to do for them."

Secondly, a release (iteration) is made up from a number of 
several-week-long (development) iterations. An (external?) release is 
made when the customers accept an iteration release. The name for the 
release acceptance activity is acceptance testing. Acceptance tests are 
derived from the user stories, and operate the system with the  user 
stories' "ACTION"s, and check for their "EXPECTED RESULT"s.

Therefore two important activities for a customer are story writing, and 
acceptance testing. There is a considerable amount of work associated 
with these activities, neither of which form part of an iteration.

Thirdly, an iteration plan is formed by breaking down the user stories 
into programming tasks of a few days long.

from:
http://www.extremeprogramming.org/rules/iterationplanning.html

"Each task should be estimated as 1, 2, or 3 ... days in duration... 
Tasks which are shorter than 1 day can be grouped together. Tasks which 
are longer than 3 days should be broken down farther. Now the project 
velocity is used again to determine if the iteration is over booked or 
not. Total up the time estimates in ideal programming days of the tasks, 
this must not exceed the project velocity from the previous iteration. 
If the iteration has too much then the customer must choose user stories 
to be put off until a later iteration (snow plowing)."

Anyway, in general, I suggest scheduling quality time for generating a 
good head of stories, spending some more quality time for estimating 
stories and planning accepted releases, adopting the recommended forms 
(1-3 week stories for release plan to last a few months, 1-3 day tasks 
for iteration plan to last a few weeks), and making sure we don't slack 
off on unit-testing and refactoring.

I hope this makes sense. If not, just read the XP site I linked to from 
the start. ;-)

It's probably worth reading the XP site I linked to from the start 
anyway. ;-)

It's all quite simple once you get the hang of it ;-)

Best regards,

John.