Let's suppose you're using XP to develop software. What should you do if upper management or the company that hires you mandates that you deliver Pert or Gantt charts so they can track your progress? XP doesn't track dependencies between user stories so this will be difficult to do. Any suggestions? -- AlejandroGoyen

''I haven't actually gotten XP started yet, but here's an idea. You could create tasks that are related to UserStories and use MS Project to do resource leveling and come up with the schedule. Don't put any dependencies between the tasks, you don't need to. You can create a summary task for completed stories and outstanding stories; then when you finish a story, mark it as 100% complete and move it under the 'completed stories' task. The only dependency would be an artificial one that says incomplete stories is dependent on completed stories.''

 V===Completed Stories===V
 [Story1]		|
 	[Story2]	|
 		[Story3]|
 			V==Incompleted Stories==V
 			[Story4]		|
 				[Story5]	|
 					[Story6]|
 						<> Estimated Finish Date

''How's that? -- RobHarwood''

Let's suppose upper management wants these Pert-Gantt charts to have dependency awareness. In that case, the above solution wouldn't be acceptable. Who should be responsible for keeping track of dependencies (Tracker? Programmer?) -- AlejandroGoyen

''Or, perhaps even more effective: Who should be responsible for eliminating all dependencies?''

And more to the point, why must there be any dependencies at all? Alejandro, are you asking from experience, or asking from speculation? If from speculation, then I propose that YouArentGonnaNeedIt. If management insists on dependencies, then just make them up! Who cares if they're not followed. The next time they want to see the Gantt chart, just reorder the dependencies so that the completed tasks come first. If you want to do XP and management wants task dependencies, just fake it. Once they start getting results they won't care about the dependencies anymore. -- RobHarwood

''I am asking from speculation. Let's picture the following scenario: Say the customer asks for 2 tasks: T1 and T2. You could implement the tasks in any order (pick any task, implement it, choose the next, refactor and repeat until all tasks are complete), but from experience you KNOW that if you develop T1 before T2 you'll solve both tasks quicker. The dev estimation phase of XP doesn't consider task dependency for velocity optimization. You know upper management wants things to be done as fast as possible. Shouldn't you track this kind of velocity dependency to optimize development? -- AlejandroGoyen''

''Just to clarify, when I say tasks I am talking about the UserStories, please dont confuse with EngineeringTask''''''s. -- AlejandroGoyen''

Please give an example of two tasks with the property that the time to do them both varies substantially depending which one you do first. One real example will do.

''What comes to mind is a typical business application in which the customer asks for multiple reports for data summary. If the customer presents both stories at the same time, it will be quicker to implement the app functionality first, then create the required reporting functionality. If you work the other way around, you might waste a lot of time creating fake data for the reports so that they make sense. -- AlejandroGoyen''

If both stories are in the same iteration, then the developers get to choose which one to do first. If they are in different iterations, then it makes sense to do whichever one the customer wants first. For details on the reasoning behind the second sentence, see ExtremeProgrammingExplainedEmbraceChange. It talks about how the customers might change their minds and delaying effort until it is definitely needed. Since this is a hypothetical example, I'm guessing that it will a) not happen, or b) not happen very often. XP has one way of dealing with it, and that is to let the customer know the dependency and give two alternative times (e.g. 4 weeks or TwoWeeks if we do story X first). This lets the customer choose whether to waste the time or not. -- RH

''I did not know XP took this into consideration, letting the users know that story Y can be done quicker if story X is done first. I thought that in the planning game the user stories were treated atomically without any dependency with other stories. But if this is the case, no more discussion is required. Thanks for clearing this up! AlejandroGoyen''

Just to clarify: Usually they are treated as atomic units; that's the normal case. The dependency thing is a special case for dealing with situations like the one you described. In any case, I clear the floor for anyone who wants to refactor this down to a short description. -- RH

From experience, I have had dependencies when incorporating large scale changes that went beyond the scope of a single release.  To get from A to B, I had to go through the intermediate stages of A1, A2, etc.  Slips in the intermediate stages need to be reflected in the schedule for the final deployment of B.  I would speculate that XP would have a similar relationship between iterations and releases.  If your iterations begin to slip or provide less than expected functionality, then your release must also begin to slip or adjust to contain less functionality.  I believe this is in line with XP practices and actually uses the Pert-Gantt charts for their intended purpose, tracking the overall release. -- WayneMack

''This sounds great, you are talking about iteration dependency. But my idea is geared towards keeping track of dependencies at the task level to optimize the implementation process. -- AlejandroGoyen''

It's a week's worth of work. Draw something sensible on a white board.