AIoT Business Viewpoint: Difference between revisions

Line 36: Line 36:


== <span id="Epics"></span>Epics ==
== <span id="Epics"></span>Epics ==
The agile approach to managing work items is to break them down in a hierarchical way. Depending on the agile method chosen, these hierarchies will includes Themes, Epics, Features, Stories, and so on. The AIoT Framework is by default assuming that Epics and Stories are used to structure work. Depending on the complexity of the project and the agile method chosen, this might have to be adapted.
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.


Nevertheless, it is important that the business model and the agile work schedule get closely aligned. This is why the AIoT Framework proposes that the business model team defines a high-level set up work packages as Epics, which can then be broken down into smaller backlog entries (e.g. user stories) by the agile teams.
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.


== Story Map ==
== Story Map ==
[[File:2.1-Example-Story-Map.png|800px|frameless|center|Example: Initial Story Map]]
[[File:2.1-Example-Story-Map.png|800px|frameless|center|Example: Initial Story Map]]

Revision as of 07:07, 27 June 2021

Business ViewpointUsage ViewpointData/Functional ViewpointImplementation ViewpointProduct ViewpointProduct ArchitectureAIoT Business Viewpoint

Business Viewpoint

The Business Viewpoint of the AIoT Product Architecture is building on the different artifacts created for the Business Model. In order to refine and validate this information, site surveys and stakeholder interviews should be performed. The definition of personas helps ensuring all key stakeholder perspectives are taken into consideration. The high-level vision and requirements are then captured as epics. From there, a story map is created to capture all high-level requirements. This is the main interface between the Business Viewpoint and the Product Viewpoint.

Business Model


Site Surveys and Stakeholder Interviews

In order to capture and validate requirements, it is common practice for IT projects to perform stakeholder interviews. This should also be done in case of an AIoT product/project.

However, an AIoT project is different in that it also involves physical assets and potentially also very specific sites, e.g. a factory. Requirements can heavily depend on the type of environment the assets are deployed in. Also, usage pattern might vastly differ, depending on the environment. Consequently, it is highly recommended for the team responsible for the product design to spend time on-site and investigate different usage scenarios in different environments.

While many AIoT solutions might be deployed at a dedicated site, this might not be true for AIoT-enabled products. Take, for example, a smart kitchen appliance, which will be sold to private households. In this particular case it can make sense to actually build a real kitchen as a test lab, to test usage of the product in a realistic environment. Or, in the case of our Vacuum Robot, different scenarios for testing the robot must be made available, including different room types, different floor surfaces (wood panel, carpet, etc), and so on.

Personas

Personas are archetypical users of the product or solution. Often, personas represent fictitious people which are based on your knowledge of real users.

The Business Viewpoint should define a comprehensive set of personas which help with modeling the product features in way that takes the perspective of different product users into consideration. By personifying personas, the product team will ideally even develop an emotional bond to key personas, since they will accompany them through an intense development process. A persona does not necessarily need a sophisticated fictitious background story, but at least it should have a real-world first name and individual icon, as shown in the example below.

AIoT Personas

Epics

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.

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.

Story Map

Example: Initial Story Map