Requirements are the backbone to any software development project (and really any project). They give the project team a sense of scope and complexity while ensuring that the user’s needs and wants are met when everything comes to a close. In typical agile development projects, requirements = user stories + acceptance criteria. The importance of a well-written user story is at times overlooked, but I want to stress that writing a user story properly can give development teams the structure they need to accurately develop solutions while guiding the work throughout the development cycle. For those of you who haven’t worked in agile software development project environments, you may be asking yourself, “what the heck is a user story? And what are acceptance criteria?” Let me explain. A user story is a description of a feature that the end user of the solution does or needs, and why. The acceptance criteria are the business rules that go along with the story. For example, a user story might be, “As an administrative user, I need to manage system users so the system remains secure and the appropriate users can access the system.” Acceptance criteria for this story might include, “only administrators have access to user management functions.” There are three main components to a user story: The who, the what, and the why. The main structure for a user story is:
As a <role>, I want/would like/should/can <function> so that <value/why>.
Notice that the “how” is left up to the development team…this is important! No one should prescribe how the development team completes a user story except the development team. This allows the team to use their expertise to fit the software to the user’s needs. So what makes a user story a well-written user story? Well-defined and focused components. Rather than starting your stories with “as a user…” consider refining to what kind of user. Is the need described in the user story specific to a certain department of users or a certain role assigned within the system? The more specific you can be with the “who,” the better able the development team is to code to that specific user’s needs. When writing the function, ensure that you are only focusing on what the user needs to do, and not how. This can be very difficult. Often times, you can imagine how a piece of software might allow you to perform a specific function – there are often two or three common ways to complete an action and it can be easy to propose that when writing a user story. Try to avoid that: allow the team to design and develop how the user’s needs will be met. I find that re-reading my user stories and asking myself if I know what I would click in the system to complete the action can tell me if I’ve determined the how in the user story rather than that what. Finally, and perhaps most importantly, do not forget to include why the user needs the ability to complete the function! This is easy to leave off of a user story, but provides the context needed so that the team knows the business value they are trying to achieve with the story. It can be a great indicator as to how far to take the solution and what functionality is truly needed by the end user. Having well-defined and documented requirements is necessary for a project to be successful. By focusing on writing complete and granular user stories in the proper format, you can rest assured that your solution will meet your end user’s needs.
2024 Netrix, LLC | All Rights Reserved.
