Agile frameworks are regarded as addressing complex problems with the simplest approach to build the most innovative solutions. The iterative and incremental approach really helps in breaking down large chunks of planned work into smaller tasks to create a Minimum Viable Product (MVP) that is enough to ascertain what is being built is right and fulfills the need.
A common practice for all frameworks that fall under the agile umbrella is having Epics, Features and User Stories which are the building blocks of every solution. Every level demands a certain level of complexity for compiling and storing the content.
In the vast and almost limitless amount of information available in today’s age, there are different names and terms used that lead to confusion, although the meaning remains the same.
In this article, we will be addressing a common cause of confusion when it comes to talking about Features and Requirements. We will walk through what are features and requirements, touching upon their differences and ending with writing features correctly and what to avoid when writing them. At the end of the article, you will also be able to download a free template for Feature writing.
What are Requirements?
A requirement consists of large or small, technical or product specific chunks of work that need to be implemented in order to enable the fulfilment of a user’s demand. It consists of the required work needed to achieve customer focused functionality.
What are Features?
A feature is a predefined, bitesize scope of customer focused functionality. These are new functionalities that can deliver customer value in the shortest amount of time. For example, two or five iterations.
The Confusion When Understanding Requirements and Features
Although the words “Requirements” and “Features” are used quite mercilessly and interchangeably in the world of agile, when you deep dive into what they really mean, their origins are fascinating.
Requirements originally emerged from the waterfall model from the time where managers would have to sign off on large amounts of requirements of variable sizes to get work done.
Eventually, with the arrival of agile methodologies, things that were considered the norm in the time of the waterfall model’s peak, eventually became a sin. Change in requirements was welcomed rather than etching the requirements in stone. The introduction of user stories disrupted the sequential pattern of the waterfall model with a focus on working on small chunks of functionality.
As for the origin of Features, they were purely done in agile. More specifically, in the Scaled Agile framework. When it comes to writing features, the easy approach taken by organizations is to bunch the user stories into one and call it a feature. That is not how it is supposed to be done. When creating a feature, it is important to have the technical requirements to be split into valuable deliverables for the organization.
Features Vs Requirements
To better understand features and requirements, let’s look at the example.
There is a system needed for the local police station that will allow police officers to report, track and monitor the crimes that are happening in the city.
Using this scenario, for the reporting module, the requirements are listed below.:
- Date of when a crime took place
- Location of offence
- Location of where the crime was reported
- Crime Type
- Name of Officer
Using the example mentioned above, an example of a feature would be “Generating Crime Report”. This way, all the requirements that are mentioned above can become a part of the feature.
Who writes the Features?
There is not a designated role in agile or any of its frameworks for who writes the features as it is a collaborative effort. Rather it is who owns the feature. The Product Owner is known for agile frameworks for this role and in the Scaled Agile Framework it is owned by the Product Manager.
Mistakes When Writing Features
Keeping a Very Technical Tone
Usually the features are written by a senior developer with a technical perspective which is good for the development team to quickly understand but can lead to a disconnect and difficulty in comprehension for everyone that is not part of the scrum team.
The absence of having a designated role can be considered one of the reasons why features are not written correctly. They need to be written by an individual that comes from the business development side, as they possess an intimate knowledge of the end user and are the ones that are close with the customer.
What normally happens is that the countless technical requirements are grouped into a list of “Features” so that progress can be monitored. Attaining an understanding of the business is as equally important as implementing it by the developers.
There needs to be a balance of covering technical and business aspects so that it addresses anyone that is part of the scrum team to easily understand. Feature writing should be a collaborative effort combining both business and technical elements.
Not Setting a Business Benefit
When writing features, the value and the benefit that a feature will provide, is not made clear. This affects prioritization of features in the backlog as it makes low level features to be worked on first as compared to the ones that will provide the most benefit. To be clear, prioritization in this case relates to the ranking of the features and which ones to do first.
Not Continuously Updating the Content
Things rapidly change in agile so it is very important to keep the document as updated as possible. As the feature is broken down into user stories, naturally, questions will arise and answers not considered when initially writing the feature. The feature should be treated as a live issue type, with all the clarifications documented. This does not mean adding to the scope of the feature but merely documenting the clarifications.
How should Features be written?
After learning about the common mistakes made when writing features, let’s focus on the elements that will make your features great and help churn out the most value from them.
A feature shall consist of six sections:
Introduction
- What the feature is and what will you achieve from it
- Who is the user and which needs will be fulfilled
- Why the feature needs to be built
- Any metric that will be used to measure the achievement or the fulfilment of the feature
Business Benefit
Requirements and Specifications
- Describe what the product will do so that it becomes clear to the reader what needs to be designed, built, tested and released
- Attach any mockups, pictures and describe the UX of the functionality
Technical Requirements
- Deployment environment(s)
- Include any APIs that need to be built
- Which items need to be stored in the database
- Sending push notifications
Design Requirements
How to Test
- Test cases
- Test suites
- Areas that can be impacted by the new feature
- Behavior in different environments
A short summary that shall cover the following:
Defining your objectives or goals that you wish to achieve from the feature.
This is where you will include the requirements of the things that will be needed to build the feature. Here is what you need to include:
In this section you shall get an input from the senior tech leaders and developers to map out what will be needed to build the feature. For example, this can include:
For the design requirements, collaborating with UX or frontend developers will be a great way to prepare a list of what needs to be a part of the feature. This may include any elements like, loaders, success messages or components used.
This section shall include what needs to be tested in the feature. It can consist of:
Template for Writing Features
Get a head start on writing your features by downloading our free template for Feature Writing here.
Conclusion
It can become quite confusing and you may feel lost in the sea of information that is available. But at the end of the day, it all comes down to preferences and what suits your organization best.
In larger organizations, the convention followed can be epics, features and user stories. However for smaller organizations, with a scrum team of 5-9 people, features and user stories may also suffice.
It is important to understand that requirements can be anything that can be used by any member of the development team. They can be certain fields, building widgets or components on a website that must be created by the developers. They could be performance targets and compliance achievements that must be done by marketing or sales individuals.
Writing your features as described above will have a very positive impact on your teams as it can boost collaboration among teams and eventually lead to having a smooth development process.
