Photo by GilmothScrum is a method used in software development that is aimed at creating software that fits the business needs better in managable projects with predictable outcomes. It can really help development projects along. There is however a big risk involved in the way selections are made what to implement, and what not.

Wikipedia tells us:

During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog,” which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed. The team then determines how much of this they can commit to complete during the next sprint.[4] During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. Development is timeboxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a sprint is completed, the team demonstrates how to use the software.

The problem here is not the fact that the Product Owner decides functionality, but that the Product Owner may not have the right information to decide on the priority of non-functional requirements that originate in the technical teams within the organisation. Security, scalability, but also conformance to architectural principles, standards and directions are sometimes sacrificed against functional traits of an application. This is risky business that can stimulate unhealthy code and poorly performing software.

The method itself does not have means in place to insert priority boosters for non-business functions which is the main cause of the problem. The Product Owner therefor shouldn’t be a single person from the business side of the organisation, but a team of stakeholders. That way a balanced feature selection proces can take place and most of the risks are averted.

What’s your take on this?