Requirements Prioritization in Agile: Use of Planning Poker for Maximizing Return on Investment

Conference paper
First Online:
Part of the Advances in Intelligent Systems and Computing book series (AISC, volume 558)

Abstract

Agile Methodologies are gaining popularity at lightning pace and have provided software industry a way to deliver products incrementally at a rapid pace. With an attempt to welcome changing requirements and incremental delivery, requirements prioritization becomes vital for the success of the product and thereby the organization. However, prioritizing requirements can become a nightmare for product owners and there is no easy way to create a product backlog, 1 to n list of prioritized requirements. For an organization to succeed, it is crucial to work first on requirements that are not only of high value to the customer but also require minimum cost and effort in order to maximize their Return On Investment (ROI). Agile values and principles talk about software craftsmanship and ways to write good quality code and thereby minimize introduction of any new technical debt. However, no solution is described on how to handle existing technical debt for legacy projects. To maintain a sustainable pace, technical debt needs to be managed efficiently so that teams are not bogged down. This paper talks about estimating priority using planning poker, modified Fibonacci series cards, and provides a multi-phase solution to create a product backlog in order to maximize ROI. This paper also provides a method of handling and prioritizing technical debt and the impact of non-functional requirements on technical debt prioritization. The solution proposed is then substantiated using an industrial case study.

Keywords

Agile Methodologies Prioritization Return on Investment (ROI) Feature Business Value (FBV) Technical Debt Value (TDV) 
This is a preview of subscription content, log in to check access.

Notes

Acknowledgment

The author thanks Dr. Lawrence Chung for his constant guidance, valuable ideas, and various references.

References

  1. 1.
    Highsmith, J., & Cockburn, A. (2001). Agile software development: The business of innovation. Computer, 34(9), 120–127.CrossRefGoogle Scholar
  2. 2.
    Marcal, A. S. C., Furtado Soares, F. S., & Belchior, A. D. (2007). Mapping CMMI project management process areas to SCRUM practices. Software Engineering Workshop, 2007. SEW 2007. 31st IEEE. IEEE.Google Scholar
  3. 3.
    Abrahamsson, P. et al. (2003). New directions on agile methods: a comparative analysis. Software Engineering, 2003. Proceedings. 25th International Conference on Software Engineering. IEEE, pp. 244–254.Google Scholar
  4. 4.
    Beck, K. (1999). Embracing change with extreme programming. Computer, 32(10), 70–77.CrossRefGoogle Scholar
  5. 5.
    Beck, K. et al. (2001). Manifesto for agile software development. Available: http://agilemanifesto.org.
  6. 6.
    Sutherland, J., Schwaber, K. (2007). The scrum papers: nuts, bolts, and origins of an agile process. Citeseer, [Online]. Available: http://scrumfoundation.com/library.
  7. 7.
    Schwaber, K. (2004). Agile project management with scrum. Redmond: Microsoft Press.MATHGoogle Scholar
  8. 8.
    Schwaber, K., & Sutherland, J. (2011). The scrum guide. Scrum Alliance. [Online]. Available: https://www.scrum.org/resources/scrum-guide.
  9. 9.
    Atkinson, R. (1999). Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. International Journal of Project Management, 17(6), 337–342.CrossRefGoogle Scholar
  10. 10.
    IEEE Computer Society. (1998). Software Engineering Standards Committee, and IEEE-SA Standards Board. IEEE Recommended Practice for Software Requirements Specifications. Institute of Electrical and Electronics Engineers.Google Scholar
  11. 11.
    Kotonya, G., & Sommerville, I. (1998). Requirements engineering: processes and techniques. Wiley Publishing, Chichester.Google Scholar
  12. 12.
    Van Lamsweerde, A. (2001). Goal-oriented requirements engineering: A guided tour. Requirements Engineering, 2001. Proceedings. Fifth IEEE International Symposium on Requirements Engineering. IEEE. p. 249, August 27–31, 2001.Google Scholar
  13. 13.
    IEEE Standards Association. (1990). Standard glossary of software engineering terminology. lEEE Std: 610–12.Google Scholar
  14. 14.
    Anton, A. I. (1997). Goal identification and refinement in the specification of software-based information systems.Google Scholar
  15. 15.
    Jarke, M., et al. (1993). Theories underlying requirements engineering: An overview of Nature at genesis. Requirements Engineering, 1993. Proceedings of IEEE International Symposium on. IEEE.Google Scholar
  16. 16.
    Lim, E., Taksande, N., & Seaman, C. (2012). A balancing act: what software practitioners have to say about technical debt. IEEE Software, 29(6), 22–27.CrossRefGoogle Scholar
  17. 17.
    Babar, M. I., Ramzan, M., & Ghayyur, S. A. K. (2011). Challenges and future trends in software requirements prioritization. Computer Networks and Information Technology (ICCNIT), 2011 International Conference on. IEEE. pp. 319–324.Google Scholar
  18. 18.
    Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley Professional.Google Scholar
  19. 19.
    Shao, P., Sample selection: An algorithm for requirements prioritization, ACM-SE 46 Proceedings of the 46th Annual Southeast Regional Conference on XX (pp. 525–526).Google Scholar
  20. 20.
    Ryan, K., & Karlsson, J. (1997). Prioritizing software requirements in an industrial setting. Proceedings of the 19th international conference on software engineering. ACM.Google Scholar
  21. 21.
    Felfernig, A., & Ninaus, G. (2012). Group recommendation algorithms for requirements prioritization. Proceedings of the third international workshop on recommendation systems for software engineering. IEEE Press.Google Scholar
  22. 22.
    Racheva, Z., Daneva, M., & Herrmann, A. (2010). A conceptual model of client-driven agile requirements prioritization: Results of a case study. Proceedings of the 2010 acm-ieee international symposium on empirical software engineering and measurement. ACM.Google Scholar
  23. 23.
    Grenning, J. (2002). Planning poker or how to avoid analysis paralysis while release planning. Hawthorn Woods: Renaissance Software Consulting 3 (2002).Google Scholar
  24. 24.
    Kruchten, P., Robert L. Nord, & Ozkaya, I. (2012). Technical Debt: From Metaphor to Theory and Practice. Ieee software 29.6 (2012).Google Scholar
  25. 25.
    Ries, E. (2009). Minimum viable product: a guide. Startup Lessons Learned.Google Scholar

Copyright information

© Springer International Publishing AG 2018

Authors and Affiliations

  1. 1.Department of Computer ScienceThe University of Texas at DallasRichardsonUSA

Personalised recommendations