Bridging communication gaps with a Feature Tree

We worked closely with the System Architect (SysA), the software Product Owner (PO), the software team and some other involved people. Early workshops showed a deep discomfort among the developers concerning the requirements and specifications.

• Too many documents in an unclear state
• One document covers content and requirements ranging from high level down to small details depending on the know-how of the writer, but overview and context are missing for the reader
• Which documents need to be up-to-date?

Too many documents in an unclear state

We found different requirements documents for different project stages with different authors (see Figure 1). The landscape of existing document types was complex, sometimes overlapping, with some gaps and all of them in a style developed years ago in a waterfall context with customer requirements specifications, system requirements specifications, and many more Word documents. Some central documents were required to pass a project gate but the quality criteria were unclear; the later use in the product development project depended on the people in the project. No requirements management beyond versions of a Word document was established. The requirements abstractions were mixed throughout the documents: in the customer requirements document (CRS) high level and very detailed requirements were side by side in a long list of requirements.

There is some information that is important during the project at some stage, but it is typically not of any further interest as soon as the project is in another phase or finished. Other information, however, should be kept up to date and may be of value after the project. How do we decide which is which? We asked the team which information would be helpful for them when they need to start with a minor release version, say version 2.3, of an existing product. Where do they look for the information now, and how could we organize it better?

With this guideline we structured the “document landscape” into product-driven documentation and project-driven documentation and added new types like coding principles and code comments to our landscape, as they also document important aspects of the product. Figure 2 illustrates an example.

Documenting different levels of requirements

The documents were typically associated with a certain level of details even though the documents of the current project did not fit the expectations. It was important to understand which people in the company have the domain knowledge, and at which detail level. The product manager is not the expert of the so-called “system check” that the production line needs for validating the built system, but has to know:

• that the system check is needed for the product,
• whom to ask, and
• that it is needed for the milestone “production-ready”.

Together with the Software Team Leader, the Product Manager (PM, a member of the marketing team) and the Product Owner (PO, a member of the software team) we structured the requirements levels as needed and based on the landscape of documents, and we found a gap that had led to many discussions between the Product Owner and the Product Manager. We bridged the gap by introducing the feature tree: the feature was the right level to hand over from PM to PO, while the tree was the structured view on the features. For the transition see Figure 3.

From a requirements level’s point of view the feature builds a bridge between the user stories of the software project’s world and the product user’s view. Each feature has its stakeholder(s): they are involved in the specification of acceptance criteria and testing and ensure adequate quality.

The feature description is often represented in table form based on a company-specific template: some items are general feature description items or fields (e.g. see Table 1), some are company-specific items.

Feature
ID & Name	nnn xxxxxxxxxxxxxxxxxxxx
Summary	Short description
Class	Core, Base, Feature
Pre-condition	Feature reference, states
Post-condition	States
Description	Stories, requirements
Remarks
Acceptance criteria
Stakeholder	[Who delivers details and tests]
Business value
Feature size	[S, M, L, XL]

The specification of a feature can be * a set of requirements (mandatory) * linked to a goal (recommended) * its business value (recommended) * linked to one or several prototypes or solution variants that exemplify how the feature is going to be implemented (recommended) * linked to test cases that are used to test conformity with the requirements of the feature (recommended) * its own acceptance criteria (recommended). ###Introducing the feature tree Features are a common abstraction level, sometimes above the epics in the hierarchy (see Figure 1), sometimes below. A feature is a set of requirements (functional and non-functional), has a business value for a stakeholder and might have dependencies. A feature lasts longer than the project and might get additional sub-features in later releases. During the development project a feature is broken down into user stories, and later into tasks, by the development team. Features have an ideal abstraction level for communication and discussion with stakeholders about how the product really needs to be valued. Features sometimes come in lists like a backlog or in tables or are sometimes visually structured: these are the feature trees. In general there are two types of feature trees: * Trees to decompose the product into different levels of features. They are visualized as a fishbone diagram ^[1] or as a mind map ^[2] or as story maps [Jeff Patton]. They show a hierarchy and help to structure features into groups and visualize dependencies. * Trees focusing on the development axis (feature vector): these trees grow from the stem to the leaves ^{[3, 4]}.

The example in figure 4 shows that the tree is compact and needs some work in advance to identify the requirements and the right order for their development. The product manager is usually not able to create such a feature tree on his own: he needs the know-how of the development team to realize it. In general, the mind map version of a feature tree is simpler and more quickly achieved. It decomposes the problem by breaking down the product into feature sets and features and delivers quick wins: * It gives all team members and stakeholders a quick overview and a rough understanding and is therefore a good starting point. * It eases discussions about in-scope vs. out-of-scope. * It shows dependencies (decomposition, vector, interdependencies of features). * It facilitates a common language: the features should be named and any naming conflict resolved. * It is expandable and flexible. The feature tree lasts as long as the product. What is hidden by many feature trees are the requirements (functional and non-functional), as they are parts of the features. Hint: In general, careful selection is required of what is visible in the tree and what is mentioned in the feature description (specification) only. Too many kinds of dependencies confuse the feature tree: try to focus on those that are the most relevant for the stakeholders. ####Developing the features as a tree (visual model) Feature vectors are a powerful technique for project planning as they show how a feature is developed over time: how much of a feature is needed for the user at a particular time, how much does it cost and does the business value justify the costs.

Feature	Increment 1	Increment 2	Increment 3	Increment 4
Service Management	Block/deblock vehicle Enter service dates Define service types and work packages	Log service history		Automatic reservation for service
Fleet Management	Define vehicle categories Enter vehicle place	Change vehicle place Search by category Search by place	Combined search Add categories dynamically	Order vehicle move to another place
User Management	Login/Logout		Change password	Set preferences

####Describing the features Developing the feature tree and describing the features is often an iterative process: while working on the details you might identify modifications for the tree and vice versa. In Table 3 some findings are listed highlighting how one might deal with them.

Aspect	Description	How to deal with it
Different types of features	Differentiation between mandatory, optional and alternative	Visual mark in the tree plus text in the feature description
Product variants	Some features might only be relevant to some product variants	If useful: visual mark Feature description: field “Product Variants” to enter all product variants that offer this feature or “all”
Dependencies of features	A feature on the same level or in a different branch might require the solution of another feature. Mind: this is a business dependency (not a technical one)!	Recommendation: describe the dependency in the description of the successor (if you show it as a link the picture gets crowded) and/or the post conditions. Additionally, link the pre-conditional requirements of other features as ‘predecessor’.
Acceptance criteria	Similar to user stories a feature also needs acceptance criteria. These criteria might be defined per vector and finally overall.	Add a field “acceptance criteria” (like it is used for user stories). Add the stakeholder (group) to accept the developed feature to close the quality loop.
Feature set (top level feature)	Does a feature set (or “base feature”) need an own work item type?	Use the feature item as a feature set is a feature of “higher” level (direct link to the root).
“Empty” feature	A feature might just indicate a category and does not have linked requirements and user stories: it just helps to structure the tree.	That is ok. Check if non-the-less acceptance criteria might be helpful. Use the feature item. If it happens in a later phase that requirements are linked to a category feature the full set of information of a feature has to be added to the item: it becomes an ordinary feature.
Business rules	Re-usable requirements can be implemented as business rules that allow adaption via parameters to fit for the purpose.	Within the feature tree the business rules are handled like an ordinary requirement.
Unsolved requirements	If the feature is built with a subset of all requirements (instead of all) it has to be defined what happens with the open requirements.	Move them to another feature in another feature set (not needed in this feature set) Move them to an existing feature within the feature set (to be developed later) Create a new feature of a higher level within the feature set Delete them (not needed any more)
Feature state	How can I handle ideas or drafts within the same feature tree?	A “state” can indicate e.g. whether a feature is merely an idea, has been checked with stakeholders or is ready to be planned by the team. Some states might not be visible in the tree view.

Color codes or frame codes can visualize additional information. For example: * a color for already developed features, another one for planned features with the next iteration or release or another upcoming increment, * a double line border for elements of the product platform or a bold border for third-party elements that are built-in, * a star in the title for must features, etc. There are many possibilities to visualize information but the important thing is to concentrate on the information needed per stakeholder group. The Project Leader wants to communicate other aspects to his steering committee than the Product Manager to the production management when he wants to check the priorities of the “system check” features.

Hint: be careful with colors. It is surprising how many people are color-blind in some way (if you are not color-blind yourself!). ###The features on the road The agile development setup was embedded in a milestone-driven project management setup. To allow planning, to handle expectations, and to prioritize the work items it was important to make visible what results are possible with the chosen setup and resources. It was important for the Project Leader but also for the management and the team. **Step 1:** Common understanding of the feature tree by Product Manager, Product Owner and Project Leader. An additional solid check with the system and/or software architect that the structure of the tree is aligned with the architectural view (otherwise: think about re-structuring the tree). **Step 2:** Common understanding of the goals per milestone (Prototype 1-3, Alpha Test, Beta Test …) **Step 3:** Identifying the features that have to be delivered per milestone.

**Step 4:** Check and define the feature vector: “how much” of the feature is needed per milestone. **Step 5:** Check dependencies and ensure that pre-conditions are included in the planning. This procedure leads to a rough prioritization of the features and their location on the time axis: the first draft of a roadmap. To ensure feasibility with the given time and resources we need to estimate the features (see step 6). **Step 6:** Estimate all features on the roadmap.

Usually, there are now too many features on the roadmap. The project leader discusses possible measures and their consequences with the product manager and the product owner, for example: fewer features, more time or more developers (if this helps and is possible). The initial effort to create and design the feature roadmap was quite high but very important. The feature roadmap developed into a central part of the project planning and coordination. ####Life cycle of the feature tree The initial phase of creating a feature tree and a feature roadmap delivers a solid base for a project. The tree is now in a living state: it grows and changes over time. New features are added, deleted or changed. In some cases the tree might have to be partly restructured to allow for a new feature. The company needs processes and roles to manage the changes and to keep the feature tree up-to-date over the lifetime of the product.

###The feature tree in action With the introduction of the feature tree changes were initiated in a number of different areas: * The Product Manager and the Product Owner worked on the same view of the project. That helped to clarify responsibilities and tasks both amongst themselves and other stakeholders. * With the feature tree the development teams had the necessary overview and were able to put the current task into context. That made it easier to clarify open points and to make solution decisions. * With the discussion “who owns the feature tree?” and is responsible for it, a general discussion on the roles and responsibilities within an R&D project was opened: changes in one area usually led to consequences in another area. We split the answers along the time axis: what is the best solution for this company now and what could be a vision for the future, or for the next project. * As the Product Manager wanted to focus on customer value and customer requirements only, the discussion was opened to the view of other stakeholders. Not only the customer has requirements, there are more sources: production, the service department and the system architect, who is responsible for re-use and platform development and therefore has a stake in solution decisions. All their requirements shape the final product. Responsibilities, roles, processes and procedures had to be defined to ensure a complete and high quality product. * Not only the requirements processes but also the quality assurance processes had to be reviewed: the feature tree, the features, their stakeholders and their acceptance criteria had to be part of the quality assurance concept as well. For example, as with the “Definition of Done” the software team used for their user stories, a “Definition of Done” was also required for the features. The general idea of the project milestones had to be compliant with the defined milestone goals that were used during the feature roadmap creation. All these aspects led to a complete update of the quality assurance concept as well as to some new procedures. Most of the initiated discussions and changes are not surprising. As the feature tree is not a technique to solve the problems of one person only but a communication vehicle it has to be embedded into the environment of the involved people – improving existing procedures, adding new ways, changing views, and giving an impulse to change in other ways as well. ###Lessons Learned and Takeaways from the project One of the main lessons learned was that the feature tree is not just a new technique but − as seen in the last section − a starting point for changes. We didn’t need a perfect tree to start, a small plant was also a good starting point. Especially the release planning aspect was highly appreciated by the customer as it led to transparency, a common understanding and therefore to more profound decisions and prioritization. #####Decomposition and vectorization The idea of decomposition was easy to grasp and delivered results quickly. The feature vectors were seen as an important additional aspect but the visualization variant as shown in Figure 3 led to misunderstandings and discussions. So we took the version of a mind map and differentiated the vector by sub-features: each vector was added as a sub-feature, the name indicated the additional business value. See also Table 2 for a vector in table form. #####The feature tree is important but not enough The feature tree allowed modifying and lightening the documents landscape: some formats were changed, some added, some documents vanished. We created a new template for the customer requirements specification and defined it as a counterpart to the feature tree. The template includes instructions that refer to the feature tree and focuses on additional information (i.e. not visible in the feature tree), or helps to explain the customer needs and the feature tree better. It also gives an overview of typical stakeholders and therefore helps to identify the stakeholders of the current context.

As soon as the usage of the feature tree is established it is recommended to review the requirements process and its products to see if they still fit: * to inspect and adapt them to improve the process in general * before starting a new feature tree to introduce the owner of the new tree and to check if new aspects might be included in the method * when new development methods are introduced to check the alignment with the requirements process in general and the feature tree in particular. #####Introduction late in the project Ideally new methods are introduced in very early stages of a project and not in the development phase. When the consulting started it was not the goal to introduce a new requirements method. Nevertheless it was the right decision, and we found ways to handle the consequences and find good solutions with the company and its teams. #####PO instead of PM Although we promoted the Product Manager as the owner of the feature tree we chose the Product Owner as “master” of the feature tree, meaning the Product Manager is responsible for the content and the Product Owner keeps it up-to-date as he works with it on a daily basis. The main reason for this decision was that the project was already running.

A consequence was that the PO had difficulties in defining features. He had the list of requirements at different levels but not the domain or customer context that was needed for the features. #####An integrated tooling solution As the responsibility for the feature tree was laid into the hands of the Product Owner we looked for a tooling solution of the feature tree that fitted best for the Product Owner. His main instrument was the Microsoft Team Foundation Server (TFS). Here were all his stories, his categories and references to his requirements – it was the central view for him and his development team. So they created a new type “feature” next to user stories and epics and used a graphical add-on to generate a tree view. From the company’s point of view the integrated tooling was a key success factor. ###The end? Although the article is written in the past the change in the requirements engineering is still going on – in the same project and in new projects as well. Once in a while a review will take place to see what works well and where there is room for improvement. There are always new events changing the set-up in an unexpected way. So we still inspect and adapt to improve the communication and synchronization. In the end it is not the technique we want to improve - though that might be a by-product - but the way people work together. ###References and Literature

• [1] Feature Tree by Seilevel: seilevel.com/ba-resources/rml-requirements-visual-models/feature-tree
• [2] Feature Tree by BAwiki: bawiki.com/wiki/techniques/feature-tree
• [3] Release Planning with Feature Trees: Industrial Case by Samuel Fricker, Susanne Schumacher, in: B. Regnell, D. Damin (Eds.) REFSQ 2012, LNCS 7195, 2012
• [4] Business-driven product planning using feature vectors and increments by Brian A. Nejmeh, Ian Thomas in: IEEE Software magazine, 2002
• [5] Agilis™ - A systemized framework the agile and lean development of systems involving multiple engineering disciplines by Zühlke Engineering AG, 2014
• [6] Requirements Abstraction Model by T. Gorschek, C.Wohlin in: Requirements Engineering Journal, Vol. 11, No. 1, 2006

####Supplementary Literature

• [7] Feature-Driven Development by Palmer & Felsing, Prentice Hall, 2002, ISBN 0-13-067615-2
• [8] Scaling Lean & Agile Development by Larman & Vodde, Addison-Wesley, 2009, ISBN-10: 0-321-48096-1
• [9] Towards a More Precise Definition of Feature Models by Matthias Riebisch, Technical University Ilmenau, Germany, 2003
• [10] Feature-oriented Requirements Satisfy Needs for Reuse and Systems View by Waldmann & Jones, published in Requirements Engineering Conference, 2009. RE '09. 17th IEEE International