Mishkin Berteig presents a situation where he proposed to a software development team, which just started to experiment with Scrum, to accept 2-days iterations. The approach was trying to tackle their organizational lack of prioritization resulting in constant crisis. Their decision led to a bigger crisis which exposed the need for task prioritization.
Tony Wong, a project management blackbelt, enumerates some practical points on individual procutivity. This article wonders how well these apply to software development and contrasts his list with that of other lists.
Scrum works most effectively with a prioritized product backlog. Prioritizing the backlog is part of the product owner role, but what can you do when your product owner won't prioritize the backlog because he or she doesn't see the value in prioritization?
The traditional agile approach to prioritization is that user stories of higher business value should be implemented before ones of lower business value. The concept is simple, but implementing it well relies on having a mechanism to assess business value. Pascal Van Cauwenberghe has recently described an approach to defining business value, called "Business Value Modeling", which may help.
The Scrum notion of 'backlog' is a single, prioritized list of user stories for the team to implement. This works well for organizing what the team should work on in the near term, e.g. during sprint planning. At the Orlando Scrum Gathering, Jeff Patton described story mapping. This is a way of organizing stories that provides richer context and can help with release planning.
