How does a Scrum team account for infrastructure tasks in the planning meeting

Given they've just been given the story during planning (regardless of it being a new story or not having estimated it earlier) you have a few choices.

First, you can ask the product owner if the story can be left on the backlog so that it can be properly checked and estimated during this sprint, and take it next sprint.

If that's not possible, another option is to do it in a spike - a time-boxed story to investigate something or to try something out - and then you'll have a head start for doing it next sprint.

Finally, if you really must start on it this sprint, then try and find out as much as you can during planning, and take the story but make it clear of the risk that it may not be completed this sprint. If it doesn't get completed, so be it, you've done some of it and now know a lot more about it for the next sprint.

Remember, estimates are just the best estimates with the information you have at the time, and can be revised later when you have more info.

Also remember you should be spending about 5%-10% of the sprint in refining the backlog. Doing this really helps keep the planning meetings shorter, more focused and more productive.

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.