Agile, order and priority
Really interesting article from the Scrum alliance drawing attention to the fact that it is best to order not prioritize on the product backlog.
For those not directly involved in Scrum, a loose definition of the product backlog is the physical or virtual display from where the scrum development team take the tasks from that they will commit to deliver in the immediate or future iterations of the product lifecycle.
Previously wisdom has said that the backlog should be prioritized but the edition of the Scrum guide states that prioritization is a technique of ordering and not the sole one at that.
The pertinent point James Coplien makes is the product owner must order the items on the backlog. They should not assign a number of items all with the same priority and leave it to the development team to decide. The idea is that the product owner fully understands the Return on Investment (ROI) and the business context, the market and competitors as well as the variables involved in the short medium and long term returns.
I think this is a perfectly valid point though depending on how many iterations there are to deliver the product backlog, factors involved in the backlog will change as neither the business or the internal or external conditions operate will remain static. There may also be indirect competing business objectives as well as other initiatives and priorities affecting the product owner.
Finally, digressing to a more high level Agile perspective, Victoria Reitano reports a recent roundtable discussion that concluded that the term Agile is no longer a buzzword and is essentially the way effective software should be delivered. It's success has been down to it's emphasis on communication and working as a team to deliver value in the product lifecycle.
Again a valid point though there are many either working within a loose waterfall approach where prioritization happens during the testing phase as bugs and issues become apparent, or what the speakers lamented as ScrumBut where the development approach is not exclusively Scrum and involves elements of other Agile processes tailored to the organization.
While they disliked the term, I believe the concept of Scrum as an adaptable framework for most organizations is a valid one. The adoption of a rigorous Scrum only approach would take time to bed into an organization as well as a range of other favorable conditions being met, such as stakeholder buy in, to work effectively.
Follow Technorati