MSBuild files are loaded and parsed in order. This means that properties and items are in scope if they have been previously defined anywhere within the load chain. Here's an example.
Test.proj
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<HelloWorld>Hello World!</HelloWorld>
</PropertyGroup>
<ItemGroup>
<Files Include="*.*"/>
</ItemGroup>
<Import Project="Test.properties" />
<Target Name="Build">
<Message Text="$(GotHere)" />
<Message Text="$(FileList)" />
</Target>
</Project>
Test.properties
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<GotHere>Got here, $(HelloWorld)</GotHere>
<FileList>@(Files)</FileList>
</PropertyGroup>
</Project>
When you run MSBuild test.proj, you will receive the following output.
Got here, Hello World!
Test.proj;Test.properties
If you were to move the Import task above the property and item definitions, your results will be different as the HelloWorld property and the Files item collection have not been defined.
This concept is important if you are attempting to break a large build file into smaller files. There may be dependencies between common properties & items and conditional properties & items. Conditional properties and items can be refactored out of the primary script (encapsulate what varies) and still use the common properties and items as long as they are defined before the conditional file is imported.