Breaking the User Story into Functional Requirements
First off, what's the difference between a user story and a functional requirement?
A user story is simple a tool used in Agile software develop that describes of a software feature from an end-user perspective. User stories are something that a user can relate to because it involves what they want to do and why. Developing and completing a user story will be a coordinated effort: it will involve a team effort including a programmer, a tester, perhaps a UI designer or database designer, certainly the project manager or team lead, and maybe others. It would be very rare for a user story to be fully developed by a single person. (And when that does happen, the person would be filling multiple of those roles.)
Another definition for a user story is that it is a thin, vertical slice of functionality, describing a small increment in value to the user (or customer).
A functional requirement, on the other hand, is either a piece of specific functionality or a component of the system that needs to be created or updated in order for the entire user story to be realized. This smaller piece of the user story is typically identified by the development team since it requires some technical understanding of systems and how they are architected. Some examples of functional requirements include:
- Create the donor table
- Create the donation table
- Write the query (or stored procedure)
- Create end user form
- Build dashboard report
- Automate create/distribution of report
- Create letter template
- Automate program to create/send letter
- Modify CSS to make site mobile friendly
The effort to design and build a functional requirement can be the task of one person or perhaps a pair of team members. Keep in mind that the goal is to finish the complete user story, so that means that collectively each critical functional requirement should be completed to build the entire user story. From a user's perspective, they see completion of the user story as the goal. From a developer's perspective, we see the user story as a collection of many functional requirements (e.g. creating/updating tables, queries, forms, reports).
Next, how do you break down the user story into functional requirements?
Explicitly or implicitly, your system has an architecture. It might be anything from a masterpiece drawn out in painstaking detail by the architecture team, to a high-level conceptual diagram. You should look at the components in your system, and ask yourself which components of your system do you need to modify (or add) to complete the user story.
Example 1: Think of a Basic System "slice"
One could say that a basic system has 3 layers (Database <--> Query <--> Form/Report). Whether it's a VB.net app or an Access database, these layers of the system exist. Thinking of a "slice" of functionality with these layers helps you consider the different functional requirements of a user story. If you were implementing a new module for your client, it may involve a modified or new table(s), an updated or new query (or stored procedure) that manages the data, and then some output of the data whether that's on a form or a report.
Example 2: Entity MVC Framework
When you built your MVC application in 333K, an update or additional feature meant potential changes to any of the parts of the system identified in this picture, which was on Katie's whiteboard in her office. Using this picture, we could think through all the parts of a system that a user story can touch and create a list of functional requirements to work on like updates to view, model, controller, and database.
Lastly, why do we break down the user story into Functional Requirements?
First, dividing a user story into functional requirements makes it easier to assign pieces of the user story to specific team members. A user story is hard to estimate without understanding the complexity of the underlying requirements. More importantly, each user story will differ in terms of feasibility and complexity; that means one user story could take 3 days to complete while another user story takes 10 days to complete. When you're starting out in your career, it takes time to learn how long something will take, so it's very valuable to be able to hear a user story and be able to break it down into requirements. This makes the user story easier to estimate in terms of time and understand how complex it is. Once you have a better idea of how long a user story could take and how complex it is, we use this information to help in the prioritization which will come later in planning.