Monday, November 24, 2008

Reconciling Plan Length

I - and many of my friends in software - work in fairly short cycles. Two weeks is the most common, really. Whether they call it SCRUM, Agile, XP, or "what we do", the process works basically the same:
  • An ordered list of things to do is provided to development
  • Development estimates the work
  • Dev and the customer (or customer proxy) draw a line at two weeks and that's what dev signs up for
This works pretty well in the short term. However, translating this to a longer work schedule is more difficult. With this process, how do you know whether you're on track for a deliverable that's 5 months away?

Okay, let's start with the process zealots: Yes, your customer should be committed to the process you're using, and should be working with the two week cycles.

And now in the real world.... we have more than one customer, and these customers have requirements and cycles that are larger than the two week development cycle. Ultimately, they need to plan development and rollout cycles in months or even years. 

I haven't actually solved this problem; I don't know how to reconcile the need to have a feature in three months and rolled out in six months with the two week planning.

Things we've tried, with various degrees of success:
  1. Stick it at "about the right place" in the backlog based on velocity and adjust a bit as it gets closer. This one often winds up with starting it a bit too late due to an overoptimistic idea of how long it will take.
  2. Create an earlier task to estimate the item, then stick it in the right place based on velocity and estimates. This works a bit better but still suffers from optimistic estimates.
  3. Put the item early in the backlog so there's plenty of time. In practice this is tenuous if you have more than one client or more than one thing going on.
What else have you tried to reconcile your development cycle with a client's longer-term plans?

No comments:

Post a Comment