[kforge-dev] user story headings, etc.
john.bywater at appropriatesoftwarefoundation.org
Fri Jan 6 15:36:24 UTC 2006
For the next phase of KForge, we wanted to firm up the "outer loop" of
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.
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
1. Clarification of the purpose and form of a user story.
2. Clarification of an iteration.
1. Purpose and Form of User Stories:
"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:
- As a [ACTOR]
- I want to [ACTION]
- So that [EXPECTED RESULT]
- Est. Benefit [POINTS]
- Est. Cost [WEEKS]
- Act. Cost [DAYS]
2. Clarification of an iteration:
Firstly, for the KForge project, an iteration is something that lasts
for three weeks each month:
"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:
"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:
"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.
"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
It's all quite simple once you get the hang of it ;-)
More information about the kforge-dev