Another, less frequently cited agile tenet is to do the riskiest work earlier. The idea here is that you avoid late surprises when risky work turns out to be expensive. Better to discover this expense earlier.
When most folks talk about the backlog order, they refer exclusively to business priority.
I think ordering or sequencing the backlog must take more than just business priority into account. Yes, business priority is important, but so are a whole host of other factors, such as early exposure of risk. Balancing these factors is part of the art of project management.
Factors to incorporate into sequencing decisions:
- Business Priority
- Dependency Order: Despite our best efforts to decompose the backlog into independent stories, the fact is, the tension between the INVEST priorities sometimes cause us to define stories that are dependent on other stories.
- Mixture: The Rock/Pebble/Sand metaphor is helpful here. Consider a bucket at the beach. If you fill it only with rocks, you have a great deal of wasted space in the bucket, due to the space between the rocks. Though it may be unable to accommodate another rock, you may be able to slip in a handful of pebbles, to fill the spaces. Following that, you may be able to slip in some sand, to fill the spaces that the pebbles were unable to occupy. So it goes with an iteration. You don't want to fill your iteration bucket with only large stories, because you're losing the opportunity to slip in smaller stories. For example - if a developer finishes a story at 3pm on a Friday afternoon, you'd probably rather have him knock off a small story in the next couple of hours rather than start a large story.
- Crowding: Many advise that agile development teams define iteration themes. This is a good concept in theory, as it allows the team to focus on accomplishing a larger goal in the iteration. The risk here is that you have your whole development team working in the same parts of the code base. This can merge issues as the team commits code to the code repository. Consider the source-code crowding problem when sequencing the work.
- Risk: As mentioned above, the earlier you schedule the risky elements of the project, the more insight you have into your completion date. One element of risk is embedded in non-functional requirements. For example - if you have performance or scalability requirements that are risky, it's better to implement the stories that are sensitive to those requirements earlier.
- User Feedback: If you have elements of the software for which user feedback is critical to making the right decisions, schedule this work earlier. If you delay these features towards the end, the need to change the system in response to the feedback becomes a schedule surprise. Worse, if you decide not to incorporate the feedback in order to make your date, your users are not just unhappy; they'll feel that their input has been ignored.
- Exercise the architecture: Scheduling the highest business value work first may avoid elements of the architecture into later in the development cycle. For example, perhaps the "happy path" of execution is deemed the higher business value. This might delay consideration of elements of exception handling to the end of the release. First pass implementations within an architecture are always riskier, and could introduce schedule surprise. It is wise to exercise all elements of the architecture as early as possible.
As I mentioned, these factors are often competing. The context of your project defines which of these dimensions are more or less important. Yes, do the highest business value work earlier, but don't forget to consider these other factors as well.
