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)
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?
- 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
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)
- parameter passing
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?
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?