Iteration Plan

The IterationPlan lists each UserStory scheduled into the fixed-time Iteration by the ReleasePlan (formerly known as 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)

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

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 LoadFactor 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

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:

print-statements (constants only)
variable declarations
read statements
simple assignment (constants and variables)
expressions
if-statements
while-statements
procedures
parameter passing

etc.

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 seems unpractical.

Or should I think of these "stories" as engineering tasks, not user stories?

Thanks, Martijn

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.

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 being created? ..