Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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!

share|improve this question
1  
"It just does not sound right considering all I know about Agile." You've answered your own question. Very good. Why ask? What more do you need to know? Your –  S.Lott Sep 19 '11 at 22:43
    
Take a look at impact mapping, it is a tool to analyse the path of achieve goals in a project, and help you decide if a path you have taken is helping you achieve a goal. It's a great tool for helping you prioristse the back log and generate stories. I think it's an equivalent or alternative tool to critical path. –  James Dunmore Jun 20 at 10:41
add comment

3 Answers

up vote 3 down vote accepted

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.

share|improve this answer
add comment

There is no longer a critical path.

At the end of every sprint you have a deliverable product. You show this to the customer in the sprint demo. If the customer likes what they see you can deliver what you have, if not then you do another sprint.

You repeat the processes. Every time the customer seems that have gained a significant amount of functionality (stories) they can take delivery of the next version.

Having a fixed deadline (every 3-6 months) and a fixed feature set is what you are trying to avoid. How can you plan for something that is 6 months away with the little knowledge you have and expect to hit both targets.

You can provide estimates but every sprint you must re-evaluate what you can achieve.

  • If you have a fixed feature set the end point will move at the end of every sprint.
  • If you have a fixed end point then the feature set will move at the end of every sprint.
  • The third leg is quality and in scrum this is the leg that should not be moved. You still need to provide unit tests and verification each sprint.

Best to have neither and let the customer accept incremental upgrades as features become available.

share|improve this answer
add comment

If you're doing Agile there shouldn't be any dependencies because you can test without having completed the part(s) you are "dependent" on. And the rare exception shouldn't be enough to make a critical path analysis worth while.

share|improve this answer
    
There's a difference between independently achievable stories and a natural path of execution. Take for example building a house - building the roof is independent of building the walls, but to be useful you would build the walls first and then put the roof in top. Building the roof first is achievable, but not ideal as it could then take longer to put in the top if you build the walls after. –  James Dunmore Jun 21 at 18:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.