The solution is not the project

To be successful with agile, the team need to think of the software product (the solution) as seperate from its delivery vehicle (the project). In all projects there are activities that support the delivery of the solution, but do not contribute to the development of the solution itself. Methodologies such as Scrum do not cater for these; Scrum is a methodology for software development, not project management.

Your solution should be defined by its features as a set of use cases or stories that are consistent with each other in detail and content. In Scrum terms, this is the product backlog. It is not a build list and should not include activities or tasks. If you have tasks in your backlog either you’re mixing project activities with solution features, you’re trying to use the backlog as a mechanism for project planning, or you’ve designed the solution in too much detail and you’re actually following waterfall principles. Working out the tasks required to develop the solution will be done during iteration planning (more on that later).

Project activities might include initiation and kickoff activities, setting-up environments, development and test frameworks, providing training, migrating data, supporting a period of formal acceptance testing, or perhaps operations documentation and support handovers. These can be estimated and planned independently.

If you mix features and tasks or project activities in the backlog, not only will your team be confused, but you not be able to estimate and track progress consistently, or manage change.