Scrum and other Agile frameworks treat requirements differently than other methodologies. In traditional software development methodologies, requirements are defined up front, and they are not flexible. Those requirements are very detailed, and if there is a need for a change, it has to be submitted through a formal process of change control because most of the times those changes are costly to implement. On the other hand, in Agile methodologies requirements are negotiable during the development and with enough details for the team to start building the software to support the functionality. User Stories are a way to express business needs, and they are simple, understandable to stakeholders and developers. Usually, they are written in cards, and they can be described as the three Cs: card, conversation, and confirmation (Jeffries, 2001). The six criteria is a handy tool to evaluate if user stories need more work (Wake, 2003). The criteria is called INVEST, and each user story is meant to be independent, negotiable, valuable, estimable, small and testable.
Techniques and Improvements
Agile methodologies provide techniques for gathering user stories. Traditional approaches involve asking the stakeholders what they want in the form of interviews but they may not know what they want at that time, but a better way is to include the different users as part of the team that is defining what to build and is continuously providing feedback of what it is being built. This technique called Active Stakeholder Participation (Ambler) is highly collaborative, users are deeply involved in defining and modeling what is going to be developed, but it’s required that those users need to learn some skills to provide information in the right direction. Also, it needs a high level of commitment because they may not be available 100% of the time, so it is essential to have dedicated users to the project to improve the involvement of stakeholders. As an improvement, users can have a prep session explaining the whole process so they understand technical aspects of the technique. Another technique is called JAD or joint application design, that involves all stakeholders in a highly structured meeting with specific roles and agenda to quickly gather information about the different requirements. JAD’s meeting needs to be planned to have a high number of stakeholder attendance, and it may be more expensive than traditional methods. Also, it may be challenging if the group is too large and requires excellent skills to the facilitator. As JAD is very structured, it is important not to restrict people when to talk or express ideas, and it is crucial to have whiteboards so people can show concepts through drawings. Contrasting to brainstorming technique, JAD goals are determined before the stakeholders are involved. JAD sessions need to be more unstructured, more informal and take place continuously throughout the project to have more effective results.
Ambler, S.W. (no date) Agile requirements modeling. Available at: http://www.agilemodeling.com/essays/agileRequirements.htm (Accessed: 2 February 2019)
Laurent, P. and Cleland-Huang, J. (2009) Requirements-gathering collaborative networks in distributed software projects, 2009 Collaboration and Intercultural Issues on Requirements: Communication, Understanding and Softskills, pp. 26–30. doi: 10.1109/CIRCUS.2009.4.
Zowghi, D. and Coulin, C. (2005) Requirements elicitation: A survey of techniques, approaches, and tools, in Aurum, A. and Wohlin, C. (eds.) Engineering and managing software requirements. Berlin: Springer, pp. 19–46.
Rubin, K (2013) Essential Scrum: A Practical Guide to the Most Popular Agile Process. Ann Arbor, Michigan. Addison-Wesley.
Jeffries, R (2001) Essential XP: Card, Conversation, Confirmation. Available at: https://xprogramming.com/articles/expcardconversationconfirmation (Last Accessed: February 2019)
Wake, W (2003) INVEST in good stories, and SMART tasks. Available at: https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ (Last Accessed: February 2019)