Stories vs Features
Developing the new features in large enterprise solutions is not easy to arrange in an agile way. The agile approach requires incremental delivery within short iterations. Community widely adopted User Stories to slice business requirements into smaller chunks that make sense from the end-user perspective. User Story works fine for the greenfield development and becomes too vague in the complex world. Implementing a simple change in the end-user experience often requires significant effort to update dozens of backend systems, untangle multiple dependencies, and verify that those changes don’t create system regression.
SAFe for many years proved to be a reliable framework to enable a customer-centric agile approach within the large enterprise solution. We need a way to break down user-centric features into smaller stories that still inherit all User Story’s great qualities and motivate developers to solve system-level problems with the user in mind, not just performing technical tasks. Multiple agile teams are combined into Agile Release Train (ART) to deliver valuable customer-centric features while respecting system complexity, architecture limitations, security compliance and other aspects expressed in the story level.
Agile feature examples and feature vs capability example you will find at scaledagileframework.com.
Agile Product Management
The Scaled Agile Framework suggests that we have a dedicated role in Product Management that should continuously research user area, customer needs, and stakeholder expectations. The prioritized feature list is the core of the Program Backlog and is the expected outcome of the exploration process. But how to connect user features with Product Backlogs of the scrum teams? Scrum Masters should organize the Feature Refinement as a collaborative and well-facilitated process similar to the backlog refinement meeting with feature refinement SAFe toolkit and purpose.
Why Refinement Process Fails
Analysis of complex user-centric features often leads to a negative result. Let’s point out the common reasons:
- Multiple functional parts of the feature are quite technical and cannot be expressed as a story from end-user perspective
- It is not clear what exactly in the scope and out f the scope of the feature
- We are losing control over big sized features
- Communication gaps lead to re-work
- Lack of standard description
- Loss of focus in discussions
To build a sound knowledge base out of a feature, we need to talk about personas, stakeholder needs, product usage context, business domain, constraints, data availability, etc. Many vital aspects can bypass the developer’s attention, re-working existing features instead of creating new ones. Feature Canvas can help us fix these problems by focusing the Scrum team to discuss more important aspects with the Product Owner than just acceptance criteria.
Feature Canvas
The Feature Canvas has a clear structure and suggests a specific flow of discussion. The design was inspired by User Story Canvas and adopted for the SAFe context.
Communication block: The first steps coloured in blue are called a communication block. At the first stage of the feature refinement process, the conversation should focus on the end-user profile who will benefit from this feature. Instead of putting the generic user persona for every feature, we should identify a more specific one (role, age, demographics, values) who will benefit most from using the new feature. The second step determines the right people to help with subject matter expertise. Steps three and four identify the customer who pays for this feature and stakeholders.
Context Block: this block revolves around user needs and describes the broader context of the potential use of the new features. Implementing acceptance criteria of the feature delivers some outputs, but providing an improved user experience contributes to the business outcomes. It’s also helpful to confirm the benefit hypothesis is still valid given the overall cost of the solution.
Solution Feasibility Block: Green steps in the canvas is represent the solution block. The discussion starts with the identification of the known constraints and risks. When all the limitations are surfaced, finding a few options of potential solutions and confirming the trade-off with the Product Owner should bring everybody to the shared page. The Product Owner often expects the developers to suggest a couple of solutions ranging from cheap and cheerful to all-inclusive. Having documented usage context, acceptance criteria, limitations, and technical solution should be enough to brainstorm story candidates that can deliver this feature incrementally within one or several Sprints: template, a couple of solutions, and acceptance criteria. A well-defined context should help express the user story positively impact the user.
Release Unit: The last steps coloured in purple focus discussion around potential implications on the release process. Developers can believe that a user story is completed when it meets acceptance criteria and the Product Owner accepts it. Every feature should be appropriately planned into a delivery pipeline, including data preparation for multi-staged testing, integration with other related features, method of collection usage data and user feedback. You need to understand how to automate the collection of usage statistics. Maybe developers should integrate the feature with Google Analytics or develop a custom solution for tracking the actual usage of new functionality.
Online Facilitation of the Refinement Meeting
The Feature Canvas works excellent on a distributed team that runs agile meetings remotely and in the meeting room. To facilitate it effectively, you can try the following:
- Prepare a board in Mural or Miro. Add to the board a high-resolution canvas
- Ensuring that the Feature Canvas will be perceived positively by the team. Short session to coach team and do some practical demonstration can help people to see the benefits.
- The process consists of four stages of 10-15 minutes. You’ll need 30 to 60 minutes to fill up the canvas, depending on the complexity of the feature and level of preparation.
- To discuss each unit of the canvas, the Scrum Master or meeting facilitator sets the timer for 10-15 minutes. When time is up, Scrum Master gather feedback, and moving discussion to the next stage.
JOIN AGILE.LIVE
- Check the nearest certification trainings at Agile.Live: Agile.Live: Advanced Scrum Master with PSM II Certification, Professional Scrum Product Owner (PSPO), Professional Agile Leadership Essentials (PAL-E).
- Connect with Agile.Live on LinkedIn
- Subscribe to Agile.Live Telegram channel
- Subscribe to Agile.Live YouTube channel