Writing effective Features
A feature is a service that fulfils 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 in a Program Increment. —Scaled Agile Framework (SAFe)
That’s how SAFe defines a feature. But is this enough to deliver high-quality feature descriptions? Why is a high level of quality important not only for the feature being implemented, but its description, too?
Get the Feature Writing Canvas from the Product Manager Tools Website
Features define what is implemented. As every software engineer knows: “garbage in, garbage out”. This is why we need to ensure that the quality of the definition actually allows us to deliver value with each feature. In contrast to enablers, we are creating the value of features not only for internal clients, who are a key stakeholder group, but first and foremost for the end user.
At Swisscom, we have joined forces with Creaholic to take a step forward in the areas of definition quality and value for the end user.
We took an iterative approach to addressing the topic in a series of workshops and sessions for a mixed pilot group made up of product managers from different divisions. While assessing the information quality of features written in the past, we quickly noticed that we still have a lot of freedom with respect to how we author information, as SAFe has not provided any more specific requirements for this so far. In many cases, for instance, the benefit hypothesis is not actually formulated as a hypothesis. For agile development, however, the benefit and hypothesis elements are both essential when writing up a feature:
- We use the term benefit because we want to create value. If the feature definition does not even indicate its value, implementing the feature is unlikely to offer the desired value either.
- We use the term hypothesis because the world is characterised by volatility, uncertainty, complexity and ambiguity (VUCA), i.e. we can only make assumptions. It is important to actually describe an assumption instead of stating a putatively fixed objective. This assumption should offer possibilities for validation, allowing the feature to be accepted or rejected after it is implemented. In turn, this can offer important insights for the future development of features. In other words, lessons should be learned.
Feature Writing Canvas
To improve the quality of features, we developed and tested a canvas:
Here we will explore three aspects of the canvas in greater detail: the benefit hypothesis, beneficiaries and acceptance criteria.
Beneficiaries
As we wish to create value for stakeholders or users, the first question to ask ourselves is: do I even know who the users are? Do I know what they need? Of course, this can often be tough to achieve for larger IT projects. Nevertheless, we should be aware that unless we are in contact with the end user, we probably will not fully understand the requirements. For this reason, we should not only follow the client’s lead, but challenge them on the questions regarding the end user — fully in the spirit of agile working.
In the canvas, this section is quite simple: a list of names or roles. But this information can also help the product manager to challenge themselves: how confident am I that I know the requirements?
Benefit hypothesis
We suggest using the following standard wording for benefit hypotheses:
If (proposition), then (benefit)
The proposition describes what we plan to develop. The benefit describes the value we expect it to deliver. There are various types of benefits can take many forms: increased efficiency, cost reduction or transparency on the business end. They might also improve satisfaction, functionality, or simplicity for the user.
The product manager who writes a feature should therefore use the canvas to challenge themselves by asking questions like: will this feature actually deliver the expected value? Is that actually what the feature will achieve? And how sure am I that it is precisely this feature that will deliver this value? Have I tried to validate this hypothesis?
Acceptance criteria
Acceptance criteria not only provide benchmarks for assessing whether implementation is on target; they should also ensure that the actual benefit is being delivered.
Acceptance criteria are used to determine whether the implementation is correct and delivers the business benefits. Acceptance criteria mitigate implementation risk and enable early validation of the benefit hypothesis. Moreover, acceptance criteria are typically the source of various stories, as well as functional tests. — Scaled Agile Framework (SAFe)
Acceptance criteria do not serve as a to-do list, nor do they describe how the feature should be implemented. They should describe the state of the system with the functional, implemented feature. They answer the question of what the minimum requirement of the proposition is to ensure that the benefit described in the benefit hypothesis can be delivered.
Benefit hypotheses and acceptance criteria can be defined in a 1:n ratio, i.e. each benefit hypothesis has at least one or more acceptance criteria.
Conclusion
A standardised writing format is the first step in improving the quality of features. This is similar to what we have seen in stories, where a specific writing format has developed and won out. The key ingredient in ensuring features offer added value, however, is motivating product managers to understand their users. This means shifting away from old task-based structures towards agile product discovery: the quest for features, talking to users, understanding their needs and validating hypotheses with prototypes.
A feature is not small-scale like a story. On the whole, we devote many resources to implementing a feature. The more precisely we understand propositions and benefits and are able to describe them, the clearer the requirement and the easier it is to move ahead with prioritization, implementation and testing. Good features are therefore a key step towards creating successful products.
Get the Feature Writing Canvas from the Product Manager Tools Website
