Product Viewpoint
The Product Viewpoint must map the other elements of the Product Architecture to the key elements of an agile product organization. The main artefact here is the agile story map, which is the highest level structural description of the entire body of work. Feature team mapping supports the mapping of the work described in the story map to the teams needed to implement the different product features. Finally, for each team and each sprint an individual sprint backlog must be created, based on the story map and the results of the feature team mappings.
Story Map
It is best practice in the agile community to break down a larger body of work into specific work items by using a hierarchical approach. Depending on the method applied, this hierarchy can include themes, epics, features and user stories.
A story map is organizing user stories in a logical way, in order to present the big picture of the product. Story maps help ensuring that user stories are well balanced, covering all important aspects of the planned solution in a similar level of detail. Story maps provide a two-dimensional graphical visualization of the Product Backlog.
The AIoT Framework is assuming the following hierarchy:
- Epic: A high-level work description, usually outlining a particular usage scenario from the perspective of one of multiple personas
- Feature: A specific feature to support an epic, which is further broken down into user stories
- User Story: short requirements written from the perspective of an end user
Depending on the complexity of the project and the agile method chosen, this might have to be adapted, e.g. by further adding themes as a way of bundling epics.
When starting to break down the body of work, one should first agree on a set of top-level epics, and ensure that they are consistent, not overlapping, and covering everything that is needed. For each epic, a small number of features should be defined. These features should functionally be independent (see the discussion on functional decomposition). Finally, features can further be broken down into user stories. User stories are short and concise descriptions of the desired functionality told from perspective of the user. User stories are often expressed in a simple sentence, e.g. as follows:
As a [persona], I [want to], [so that].
The 'persona' tells us who this feature is built for. The 'I [want to]' describes what the persona is trying to achieve (independent of the specific implementation). The '[ so that]' describes how the feature is fitting into the bigger picture.
The example shown here is the story map for the ACME:Vac product. It has 6 epics, including HMI, Cleaning, Maps, Navigation/Sensing, Configuration and Status/History. Each epic is broken down into a small number of key features supporting the epic. User stories are not shown on this level.
Feature Team Mapping
One of the main challenges in almost all product organizations is to create an efficient mapping between the organizational structure and the product structure (the same applies to projects and solutions). The problem here is that organizations are often more structured around skills (UX, frontend, backend, testing, etc.), while product features usually require a mixture of these skills.
Consequently, the AIoT Playbook is recommending an approach based on feature teams, which are assigned on demand to match the requirements of a specific feature. See Agile AIoT Organization for a more detailed discussion. Feature teams can exist for longer period of times, spanning multiple sprints - if the complexity of the feature is requiring this.
In the example shown here, the user story "Change cleaning mode" (part of the cleaning mode configuration feature) is analyzed. The result of the analysis shows that a number of components on the robovac, the cloud and the mobile app must be created or extended in order to support this user story. A similar analysis must be done for all other user stories of the overarching feature, before a proposal for the supporting feature team can be made. In thus case, the feature team must include a domain expert, an embedded developer, a cloud developer, a mobile app developer, and an integration/test expert. To support the scrum approach, it also has to be agreed who in the feature team plays the role of product (or feature) owner, as well as the scrum master.
Sprint backlogs
The sprint backlog comes from the product backlog, but it contains only that item, or those items, that can be completed during each agile sprint. ... Unlike the product backlog, though, the sprint backlog is unchanged during the period of the sprint. It can be changed, but only during the sprint planning meeting.