The IterationPlan lists each UserStory scheduled into the fixed-time Iteration by the CommitmentSchedule. Associated with each UserStory is every EngineeringTask required to implement the story.
Associated with each EngineeringTask is the name of the Engineer who signed up for the task, and her estimate in IdealProgrammingTime for the task.
Engineers sign up for as much IdealProgrammingTime as they have available. This is TimePresentThisIteration divided by LoadFactor.
Iteration Plan Summary (an example)
Given your 3 week iterations and your load factor giving each developer
6 perfect programming days this leaves each developer somewhat unloaded,
but it seems safe to assume you're shortening the iteration for this example
- yes? So that gets back to the question about what sort of activities you
conduct at the end of an iteration. A review? Rescheduling? BeerOclock? Or just business as usual?--PeterMerel
Yes, just an example of the report format. We usually have pizza
for lunch on end-of-iteration Friday. We've usually reviewed during the
week and Tracker is supposed to know what is going on at all times. (See
for a description of how Tracker knows.) Tracker collects story cards as
they are done, and at the end of the iteration even if not done, and turns
them back to the customer for rescheduling or deferral. We don't do a formal
end of iteration review. Our every-day StandupMeeting's plus our ongoing habit of communicating covers most of what we need to know. --R
- Disability Plan Redesign
- Richard: 0.5 days: 45 Transaction input
- Brian: 1.0 days: DAP Counter corrections
- Supplemental Unemployment Benefit
- Ralph: 1.0 days: Take deduction based on catalog
- Ann: 0.5 days: Load UPGUA history tables
How important is the number 3-weeks to XP? Would 6 weeks be OK and still be XP? Would 12 weeks? thanks
2 would be OK but feels short. 4 would, but it turns into a month,
which might be OK. IMO 6 weeks between measurable milestones is too long.
What advantage might longer iterations have? --RonJeffries
In your example iteration plan you have different people working on different tasks for the same UserStory. Perhaps some of the tasks will be implemented concurrently. Doesn't that make it harder to integrate the tasks? The whole UserStory has at least one FunctionalTest, courtesy of the GoldOwner
. But you have to come up with your own unit tests. Have you ever had trouble
finding matching unit tests for the different tasks? MartijnMeijering
Different people pairing (should this be "working"?) on tasks for the same UserStory tend to pair, at least some of the time, so there is no problem with integration. It was never hard to come up with UnitTest's- I'm not sure why, it just wasn't. --KentBeck
Sometimes it is hard coming up with good tests. There is a tendency
on C3 to compute an entire paycheck to test some things, which to me was
always "too big" a test. Some wise folks disagree, however. And there are
some testing "tricks". Like the one where you test a report program by sending
it known data and comparing the report file to a known good one. Seems that
one is hard to invent, easy to remember. --RonJeffries
Perhaps I don't have a good feel yet for the right size of an Engineering Task.
I have been writing a simple compiler for our compiler construction course. These are what I thought were my user stories:
Each of these meant parsing, generating intermediate code, generating
final code and extending the instruction set of my MIPS-emulator running
the tests. If you have a precise specification of a parse tree you can have
someone implement the parsing and someone else the code generation, but it
Or should I think of these "stories" as engineering tasks, not user stories?
BTW I've put a CVS repository of the compiler on my home page. Perhaps
the experts can have a look at it and determine if it is extreme.
- print-statements (constants only)
- variable declarations
- read statements
- simple assignment (constants and variables)
- parameter passing
The biggest distinction between stories and tasks is that stories are
things customers care about and tasks are things engineers care about. If
you have a larger team (5-10?), it is useful to make the distinction for
scheduling purposes. If you have large stories, it is useful to make the
distinction so you can have some feedback at the beginning of an iteration
if you are going to make it.
For smaller teams with smaller stories I have used stories directly. --KentBeck
Because a story is what a customer/user cares about, it is possible
a small story could result in a number of engineering tasks. This may be
particularly true in the first iterations of a complex system. How is the
development of an initial framework catered for? Or is it assumed that the
first iterations will develop less stories because a lot of framework is
EditText of this page
(last edited May 21, 2001)
FindPage by searching (or browse LikePages or take a VisualTour)