2.04.2010

Using the concept of Impact in your sprint planning

The most common problem I see with people chartered with execution plans (project managers, program managers, whatever) is their blind scheduling of tasks using only priority and resources as their criteria. Let's take an extreme example. Assume you have two deliverables: the first is considered "highest priority," will result in a 10x decrease in operational costs, and will take 12 months to implement. The second one is not considered as high of a priority. It will result in a 5% decrease in operational costs, and will take 5 days to implement.

In my experience (assuming there are ample resources for deliverable #1), most execution planners will blindly execute the first deliverable followed by the second deliverable based on priority rather than consider the impact of reducing 5% of operating costs over the coming year. This is because most people who are chartered with execution have been considition to look at priority first, and resources second when scheduling work to be done.

Of course in the real world things are not so cut-and-dry and not so drastic. But the point is still the same: you should set your execution plan to maximize your output as a function of time. And here's the kicker: that should be your only criteria. And it's simple, really: start plotting out impact over time on a chart and look at the "area under the curve." Compare your scheduling options and you'll see why scheduling by impact is the best way to deliver value.

Most people will ask me at this point "but doesn't priority cover impact?" And the answer is "yes but's that irrelevant." It's irrelevant because it covers the impact of the deliverable only. It doesn't take into account impact as a function of schedule - the idea that changing around the scheduling of tasks will have different total impact over time.

Give it try on your current project. And start delivering value, sooner.