Requirements Prioritization in Agile Projects: Insights from a Case Study
Reviewed by Neil Ernst / 2011-07-04
Keywords: Organizational Behavior, Requirements
Racheva2010 Zornitza Racheva, Maya Daneva, Klaas Sikkel, Andrea Herrmann, and Roel Wieringa: "Do We Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study". 2010 18th IEEE International Requirements Engineering Conference, 10.1109/re.2010.27.
Requirements prioritization is an essential mechanism of agile software development approaches. It maximizes the value delivered to the clients and accommodates changing requirements. This paper presents results of an exploratory cross-case study on agile prioritization and business value delivery processes in eight software organizations. We found that some explicit and fundamental assumptions of agile requirement prioritization approaches, as described in the agile literature on best practices, do not hold in all agile project contexts in our study. These are (i) the driving role of the client in the value creation process, (ii) the prevailing position of business value as a main prioritization criterion, (iii) the role of the prioritization process for project goal achievement. This implies that these assumptions have to be reframed and that the approaches to requirements prioritization for value creation need to be extended.
Mention the phrase "requirements engineering" to many software developers and you'll get a groan. For a long time, requirements engineering (elicitation, analysis, modeling, etc.) has been seen as something you do to satisfy the paper-pushers. There's even a derogatory acronym: BRUF, Big Requirements Up Front. Nevertheless, the fact remains that we typically build software to satisfy a user, even if the user is ourselves. Doing so requires us to think about what we should build, and, hopefully, why we are building it. While requirements may take different forms (user stories, tasks, use cases), they remain fundamental to the process of building software.
This paper points out that the problem of prioritizing requirements is even more of a concern in agile methodologies than other approaches. This is because short cycle times require frequent prioritization of the backlog. To do so, both XP and Scrum, for instance, call for an involved customer. However, this study found that this was rarely possible, and that as a result prioritization was done by the developers. Customers either found planning meetings too technical, or were not aware of their own requirements. They also found a difference in the understanding of the "value" of a requirement: there is a distinct difference between the value for the customer and the value for the developer. For example, developers might prefer to re-use solutions from other projects. Racheva et al. did find, though, that the notion of frequent, short iterations with re-prioritization was highly useful, in particular for dealing with new information and unclear requirements.