Mike Cohn in Agile Estimating and Planning, page 154, defines a "natural order" for implementing user stories – this, according to him, is a intuitive sequence that makes sense to both developers and the team. I understand and endorse this idea.
Though, I am having trouble letting go the concept of "critical path"; I see the value of ordering stories based on their dependencies. Even if the backlog is an always evolving tool, we could derive the "critical path" of the current backlog to prioritize and derive for 3-6 months worth of releases. It just does not sound right considering all I know about Agile.
How do you apply the concept of critical path in Scrum?
Your personal opinion would be much appreciated!
Best Answer
Critical path thinking comes from trying to predict the future and guess where/how bottlenecks may occur or where risks are likely to eventuate and cause us problems and then organising the rest of the development activities around those bottlenecks/risks so that the important features can be "guaranteed" for delivery.
In some respects this is an aspect of lean thinking and trying to optimise flow though the development process, unfortunately it usually doesn't get borne out that way because it's treated as an up front waterfall style exercise and never reviewed as development progresses. The reality is we have bottlenecks and risks all over the place and they tend to change over time as the team works through development. It's how we adapt to those that is important.
In Scrum we avoid the useless effort of predicting the future by doing small batches of work and then inspecting our progress and adapting planned activities for the next small batch based on the results of our previous work, on the risks that have actually eventuated and the most valuable features we need next.
It doesn't mean we can't do some initial thinking about risks and delivery order for features. In scrum we do this by working with the product owner so that they order the product backlog with the high risk/high value items coming first. Additionally we manage bottlenecks by monitoring our velocity and ensuring that we think about where we're going slow and how to improve that during each and every spring retrospective.
So whilst Scrum doesn't have any critical path planning component to it, the process itself embeds this thinking in it directly. We deliver the "critical" items early on and deal with any risks that we think may occur so that we have time to make any adjustments for our future plans based on what eventuates, whilst still ensuring the customer gets what they need the most as soon as possible.