Prioritising Stories on Business Value or Development Efficiency

During one of my annual pilgrimages to the XPDay un-conference a few years ago, a core principle in Agile software development was discussed; that of prioritising user stories based on business value. It's generally understood this is essential not only to deliver value as soon as possible, but also to gain trust and credit with business stakeholders. During this session, the alternative strategy of prioritising based on development efficiency was raised, and I thought this blog post might prompt others to have this discussion.

To demonstrate these opposing prioritising forces, let's imagine an in-house Agile team is formed to develop a simple customer relationship management tool for the sales department. The purpose of this system is two fold; 1. to capture and disseminate customer engagement activities to directly support the sales team and 2. to assist the sales management team/ focus activities on the most important customers based on organisation strategy, profitability and other currently unknown factors using a set of management reports.

During the initial phase of the project, a set of user stories describing both the CRUD and reporting requirements are written down on cards and prioritised by key business stakeholders. These stakeholders place a higher priority on the reporting cards as these directly support a key business driver of maximising return on the investment of sales activity.

It's easy to assume the broadly CRUD requirements for managing customer interactions would suit an normalised relational database model with it's approach of minimising data duplication. However, the large data volumes coupled with complex and expensive SQL queries required for the reporting requirements may be best served with a de-normalised database model.

During a project inception meeting, one of the developers suggests the cards should be played in a different order; one that focuses on development efficiency. The developers justification is well thought out - 'Delivering an initially de-normalised schema to support the reporting functionality will require significant normalisation changes for most if not all of the CRUD user stories. This significant rework could be reduced or even eliminated if the cards were re-prioritised based on impact to the database model, rather than business value. It would be more efficient to play the CRUD cards first in order to evolve the normalised database structure, and once complete, provide support for reporting by using database views requiring little changes to the CRUD supporting tables.'

Now, place yourself in the position of the product owner - how would you respond to this developers suggestion? Would you advise the business stakeholders to re-prioritise the cards based on architectural impact and development efficiency? Or, would you continue to follow the general agile approach of prioritising on business value?

This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.