Grasping the concept of working in an agile framework is not as complicated as it seems. They assist in developing complex products within the shortest sustainable time guided by a simple approach. But with the vast amount of information available on the internet, understanding the basic elements can become difficult when different terms are used to describe key elements of an agile framework.
Similar to uncovering the differences between requirements and features, in this article, we will explore and clarify the differences between features, categories and with a slight focus on the part that systems play in this arrangement, while shedding light on the problems that are associated with their understanding and how to avoid them.
What is Feature?
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. It expresses more than one of a customer’s needs which conveys a higher level objective.
What is a Category?
A category is a broader term, essentially consisting of features, that define a common characteristic and spans a wide area of focus that helps keep an organization maintain a track of their goals.
What is a System?
A system is the mechanism, component or technical product that will allow the building of these features. It can consist of all the technical building blocks like widgets, libraries and utilities that can be used for the creation of one or more than one features.
Understanding Features and Categories with an Example
Imagine that there is a website that lets you book train tickets for your journey within a city. This website will allow you to search for a train by adding a time and date, selecting your train and then paying for the ticket. You can also register yourself as a regular traveler and receive email notifications for when your journey starts.
To understand where features fall in this arrangement, it is important to know what journey a user can take on the website that will eventually provide them with value. The picture below shows the multiple scenarios in which value can be generated.
Features in this case will be enhancements which will be separate journeys that a user takes.
From the diagram above, a user can just buy one ticket by searching for a ticket by selecting a date and time for the train, booking it and then paying for it. Another journey could be a user creating an account on the website, who regularly purchases tickets and can get discounts and offers for tickets.
The first feature can look like this:
“As a customer, I want to Search for a Train Ticket Online”
Having implemented the first feature, the second feature (enhancement) can be:
“As a customer, I want to Book a Train Ticket Online”
With the first and second feature having been released, the third feature can be:
“As a customer, I want to Pay for the Train Ticket Online”
So far the user can find, book and pay for the ticket. Now the next enhancement may be
“As a customer, I want to Create an Account so that I can get discount for my Train Ticket”
Further enhancements can include receiving emails for the updates of the trains’ arrivals and departures and integrating other train lines that are functioning in another city and offer the ability to book intercity trains.
All of these scenarios are considered features and it is important to notice for all of them that each of them ends with providing value to the end user. It is also important to notice that all these features are releasable and will be released in a prioritized order.
Features have to be written by an individual that possesses the accurate and updated knowledge of the business. They should be documented in a way that they have a neutral tone that is understandable by not just the IT but rather all the various departments of an organization.
These features can also be considered as product enhancements and can be used across multiple systems. It is important to differentiate between product enhancements and system enhancements.
From the image above, you can see that there are various systems involved that assist the creation of the features. For example, the “My Account” system can consist of all the necessary technical elements required to help in building the feature. You can see that is also being used for Features “Book a Ticket” and “Creating an Account”.
It is important to keep in mind that the requirements definition of any system has to be done with collaboration of the System Architect, CTO or Tech leads. These are what have to be used at a developer level rather than a business level. The system does not provide any value on its own but has to work in liaison with the business to produce value.
The Common Problems
Theoretically, the idea of having categories is great as it helps in managing what needs to be built more effectively. The problems arise when features and categories are considered equal and completing one feature means completing one category. This is not how features and categories work.Here are the four common problems that exist when it comes to considering features and categories the same thing.
1) Estimating Categories
How it is Being Done
Categories are estimated instead of estimating features. These estimates are presented to business stakeholders, who confuse it with the completion of features or functionality delivery. In reality, completing a category or system may take several months. This of course can cause disagreements and makes it difficult to plan or forecast anything from the business.
How it is Supposed to be Done
When starting to work on any feature, it needs to be estimated across all of the systems that need to be enhanced to incrementally enhance the functionality. Ideally, when a feature is estimated, its completion can range anywhere between 2 to 3 Iterations or sprints. Categories however, can only be estimated on a higher level. These estimations can then be used to compare with other categories for prioritization and possible financial purposes.
2) Abandoning the Incremental Approach
How it is Being Done
When working on categories, all the features are bunched to make one category. This approach is a direct blow to the philosophy of any agile framework as every agile framework, incremental development is highly stressed.
How it is Supposed to be Done
Features need to be built bit by bit, eventually contributing towards building the category. A category is meant to consist of executable deliverables that constitute the completion of it.
3) Reduces Creativity
How it is Being Done
Development is focused on the category, rather than the individual features. This takes away the swiftness of adapting to changing requirements and does not leave room for creating innovative solutions when the focus is on the system or category.
How it is Supposed to be Done
Keep the development focused solely on customer facing features. It will give the room for creativity to flourish and to create exactly what is needed by the end user. Also giving Business a chance to plan their priorities.
Conclusion
If you are tracking a category, then you would not be able to track the progress of the features. If the feature was written as a part of a systems documentation, we would only see enhancements to the system and not the valuable customer functionality. In both cases, the focus on features will be completely lost. Remember, focusing on providing value to the user, eventually means thinking and maintaining a Feature Focused perspective on getting development done.
To ensure that the features cover all the elements that need to be covered, they need to be written with a business perspective. It is only then you have the accurate knowledge of what is really required by the customer. It also makes it easier for other departments of an organization to comprehend. This will provide you with the ability to understand the customer journey maps and inspect and adapt if needed. Features written by people looking after systems in IT often fail to capture the true essence of the customer’s needs.
