Introduction
Features are the building blocks of any product. Customers value features and pay for them. In a software product, they’re the pieces that form the foundation for all other parts of an application. Without features, there would be no code, no design, and no product.
In this article, we will explore the importance of the features as a layer from an agile methodology point of view and establish their importance in agile work management platforms. We will also look at what goes missing when agile management software tools try to over simplify and skip these layers.
Feature: Definition in SAFe Agile Framework
In the Scaled Agile Framework (© Scaled Agile, Inc.), a feature is defined as a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).
In simpler terms, a feature is a piece of functionality that makes something work. It’s what users expect when they use an application. Features are sized and targeted for a PI. Features can span across multiple sprints, but must be completed within a PI.
Features bridge the gap between stories and epics. Like Program Epics, Features can represent business or enabler work.
Features Vs. User Stories
A user story is a very simple, user understandable plain text which is a deliverable. A group of such related stories form Features. which, the end user receives as a single package of functionality at once.
Features are one of the key elements of any project. They’re also one of the most misunderstood aspects of software development. Many people confuse features with user stories. This confusion leads to a lot of wasted effort.
Feature Creation
Features are created by the product manager for an agile release train (ART). They flow through a program Kanban system. Part of that is the program backlog, where the features are prioritized by the product manager. Features get broken down into stories by agile teams at program increment (PI) planning events.
Features must be small enough to be delivered in a single PI by a single ART.
Feature Completion
A feature is an individual piece of functionality that will make life easier for users. It’s not just a collection of screens or pages. A feature should be able to stand alone as a complete solution.
The amount of progress done and the Minimum Marketable Feature adds up to the ‘Feature Complete’ definition. Meaning, a Feature might be implemented, but not ‘Finished’ yet as there might be some bugs to be fixed or some issues with implementation. It is important that we assess feature completion in small increments and quickly resolve the problems. Thus, making it beneficial for the next plan of release.
The Importance of Features – A Multidimensional Perspective
When you carefully think about what features are, it is quite apparent that they are a very useful piece in the agile development methodology.
The Customer Perspective
From a customer perspective, they are meaningful pieces of software that make sense. The customer judges the value of software through these pieces. In fact, this is what the user is paying for!
Thus the presence of features in an agile work management platform, empowers the agile practitioner to think from the customer perspective. In fact, we know that agile is all about delivering working pieces of software as often as possible. The presence of features in your agile work management system is a signal that you are truly following the agile methodology.
The Program Management Perspective
In Agile Methodology, delivery happens through Program Management. The delivery timeline is divided into Program Increments and each Program Increment is divided further into Sprints. As discussed above, a feature is deliverable within a PI. Thus, every PI can be thought of as a bundle of features.
Every Program Manager has to work with customers on the one hand and with business owners on the other. By using the features bundle within a PI as an anchor, the Program Manager can signal the utility of the release to the user. She can also communicate the business value of agile work to the business owner.
The Work Management Perspective
From a work management perspective, the Program Manager can understand the business and the customer priorities and prioritize the feature delivery in a way that meets both requirements. Further, teams can be empowered to take up work(user stories) based on the priorities set by the program managers.
This creates a complete alignment from business owners to end users. Such alignment produces the best results for all stakeholders. Thus, the presence of features as a layer between Epics and User Stories in your agile work management software, signals the presence of a powerful management tool in the hands of the program manager.
The Solution Management Point of View
If the Program Management answers the “when” side of agile work, the solution management answers the “what” side of agile work. As part of solution management, solution architects need to know what has already been accomplished.
Thus, they can use the feature bundle of each PI to see which part of the solution is currently being worked upon. They can also evaluate if that release is according to the priorities and dependencies of the overall solution. They can connect with the program manager from time to time and signal any changes required.
Features in Prakya
- You can create features as a part of an Epic. Epics are broken down into Features. Portfolio Epics are part of the solution backlog.
- Each feature has to be assigned to a Program. The program manager can see the feature in the program backlog and assign it a priority.
- Once a feature is added to a program, the user stories of the feature appear in the team backlog. The team can then use a Kanban workflow to complete the user stories.
- The feature progress is automatically tracked and changes are made to the program Kanban.
- Each program takes up work from different solutions, which can be configured at the time of program creation. Thus, each feature that you attach to a program also appears in the solution backlog.
- Prakya has a visual orchestrator called 3EE6TY for solution development. Features can be attached to different components that the solution architect wants to develop and the progress of the solution can be visually tracked by the solution architect.
Feature Management – Prakya’s Recommended Best practices
To manage Features in a better way, Prakya recommends some of the best practices that are listed below:
1. Focus on User’s Benefit
A feature is supposed to deliver a considerable amount of benefit to the user. Users should gain some business value out of the service delivered. Developing a hypothesis that focuses on the benefits that a user can gain by implementing a feature is one of the best practices Prakya follows.
2. Estimate and Evaluate
By focusing on simple to complex factors, the service value that’s provided by the Prakya to the users is estimated.
- Number of users who use the features
- Time taken to develop the feature
- Time taken by each feature to fit in the program Increment
- Time taken for each feature to be released
- Amount of benefit that is provided to the user
The above factors are estimated and evaluated as a second step which is a best practice that Prakya recommends. As it gives the reality check whether a feature can be handled, managed and delivered within the release train.
3. Document Technical Details
All the Technical details of Feature are well documented while adding a Feature and before assigning it to the Program Sprint. Some of the details mentioned below help throughout the Feature life cycle.
- Title of the Feature
- Feature Description
- Epic the Feature belongs to
- Priority to be assigned to a Feature
- List of components that Feature belongs to
- Supporting documents that can be uploaded
4. Define and Assign
Well described Features need to be defined and accepted as they are the way to measure the progress of product development. The status of Features is defined once it’s described and is assigned to a Program.
Conclusion
In this article we have seen why Features are an important and central part of SAFe agile. We also have seen that Prakya uses features in a strategic way to build a multidimensional view of agile work to different stakeholders and user personas such as Program Managers, Solution Architects, Business Owners and Customers. Our best practice recommendations stem from our years of expertise in Agile work management.
We would be more than glad to show you how Prakya works, in case you want to leverage our best practices. Click here for booking your demo.
