Baking in time for support

Hi LP,

I’ve broken up my project into small sprints each of which culminate in a release to the customer. However from experience I know that there will be a certain amount of time supporting the customer on each release. What I don’t know is what form each support request will take, be that a bug report or some tutoring or something else. Until such requests come in my team should work on items in the next sprint.

What I’d like to do is plan in up front 1 week of support to a particular release. When I get support requests against that release I would then like to bill the time against that block of pre allocated time.

When I am satisfied that no more requests are coming in against this release I can close the block of time. If my estimate has been good then the sum of the work of all items billed against this block will equal the estimate of the block itself. If I have over estimated when I close the block my schedule will shrink, if I have underestimated my schedule will grow.

I am not sure the nicest way to model this.

Can you give any advice here.

Regards

Brad

Hi Brad – we’ve given this much thought. Our current thinking is that the best way to handle this is with a technique vs. a feature. We are tryng this out in our own plan right now.

We are experimenting with a “Reserve” sub-container positioned at the bottom of our Sprint (lowest priority). Each person gets 3-5 days of low priority reserve that rolls up into the Sprint container. Each week at our status review, we look at the schedule and decide if the reserve is too much, too little, or just right; we call this “trimming”.

Since the reserve is meant to represent the work we know will be added during the sprint (we learned this from review of past sprints); we should be able to decrement it each week as the new tasks come in. If we can’t decrease the work, then we didn’t allocate enough up front and have a built in alert driver.

Note that in an upcoming release, any task that does not come in by the promise date of the project will get red-flagged; right now only the project does. This means that individuals will get red alerts on their dashboards if their reserve needs attention – we think that’s pretty cool and means the PM does not need to nag people so much.

I like this overall approach because you don’t have to learn a new feature. It also let’s me see with each sprint how we did on our estimation of unknown tasks by using the same tools we use to analyze known tasks and projects. I can also use the comment feature to track the reasons why we increased or decreased the reserve.

Thoughts?

Charles.

p.s. I really appreciate all your feedback Brad. Melinda is looking for people who might be interested in reviewing early designs of upcoming features. If this sounds like something you are interested in, please keep an eye out for that.

I tried a little experiment. We have five sprints schedules. I break a sprint down like this

• ITEMS
• release

In capitals are projects and lowers are tasks. I have made release depend on items and as project manager I am responsible for it. However I have no items scheduled for this sprint and can work on items scheduled for later sprints. Each sprint is modelled identically. However LP generates an unexpected schedule. I now have two weeks before the release task for the current task is scheduled to start as it is blocked on completion of all tasks in items. Two weeks of slack time not scheduled to do anything. However I have plenty to do scheduled for later sprints that have no dependencies. Why doesn’t LP fill the slack time which I have available now with later work?

I understand that the project view is a priority queue. However when a high priority task is blocked on a dependency lower priority tasks should be scheduled in until the higher priority task is unblocked. When the higher priority task becomes unblocked the system needs to reschedule. This should be modeled in the schedule view as the low priority task being worked upon and then stopped and the high priority task being picked up. Once the high priority task is finished the low priority task can be picked up again.

It is just like real time thread scheduling. When a high priority thread is blocked on IO lower priority threads have a chance to run.

Currently LP gives me a very bad expected completion time for my current project modelling because of all the unfilled slack time.

I can solve the problem by moving my later scheduled items into the earlier sprint but that would be conceptually wrong as they are not really required as a delivery in that sprint and if they are not completed then I hold up delivery of that sprint unnecessarily.

Regards

Brad

Hi Brad,

I hear you, we’ve been mulling this one over. Right now dependancies (and delay until) can create slack. We’ve been thinking of flowing work automatically as well as showing slack on the schedule. Having people pull tasks up into the gap was our original idea, but your point is well taken.

I recommend you set it up a bit differently. First don’t use dependancies. Set up your sprints, say S10, S11, and S12 with Delay Until dates set to where you expect them to start, lets say 5/1, 6/1, and 7/1. Set at least one promise date on the sprint as a whole (eg. S10 – promise 5/30). Set additional promise dates on sub-projects (milestones) in the sprint if that makes sense (eg. ITEMS – promise 5/20).

This is how we do it and it works pretty well. If the bar goes red, we know we are overloading the sprint. We can look at the different Analysis reports to access the workload in the sprint. The slack will be clustered at the end of the current sprint (a good place for it to be). If you want people to get an early start on the next sprint, you can relax the delay until on the subsequent sprint by a week or even entirely if you see fit.

The key thing is put those promise dates in and let things flow, that’s when the power of the scheduling engine is at it’s best. Promise dates work best on project containers vs. individual tasks.

Charles.