AIoT Product Viewpoint: Difference between revisions

No edit summary
 
(37 intermediate revisions by 3 users not shown)
Line 1: Line 1:
__NOTOC__
 
<imagemap>
<imagemap>
Image:2.2-v-ProductViewpoint.png|800px|frameless|center|AIoT Product Viewpoint
Image:2.2-v-ProductViewpoint.png|800px|frameless|center|AIoT Product Viewpoint


rect 0 274 432 561 [[Solution_Architecture|AIoT Solution Architecture]]
rect 698 59 2421 430 [[AIoT_Business_Viewpoint|Business Viewpoint]]
rect 702 485 2425 859 [[AIoT_Usage_Viewpoint|Usage Viewpoint]]
rect 702 911 2433 1281 [[AIoT_Data_and_Functional_Viewpoint|Data/Functional Viewpoint]]
rect 706 1337 2440 1715 [[AIoT_Implementation_Viewpoint|Implementation Viewpoint]]
rect 2468 55 3122 1711 [[AIoT_Product_Viewpoint|Product Viewpoint]]
rect 1 1041 146 1191 [[Product_Architecture|Product Architecture]]
 
desc none
</imagemap>
__NOTOC__
<s data-category="AIoTFramework"></s>
 
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.
 
__TOC__
 
= <span id="StoryMap"></span>Story Map =
It is best practice in the agile community to breakdown a larger body of work into specific work items using a hierarchical approach. Depending on the method applied, this hierarchy could include themes, epics, features, and user stories.
 
A story map organizes user stories in a logical way to present the big picture of the product. Story maps help ensure that user stories are well balanced, covering all important aspects of the planned solution at a similar level of detail. Story maps provide a two-dimensional graphical visualization of the Product Backlog. Many modern development support tools (such as Jira) support automatic visualization of the product backlog as a story map.
 
The AIoT Framework assumes 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
* 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 may need 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, do not overlap, and cover 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 [[AIoT_Data_and_Functional_Viewpoint|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 the perspective of the user.
 
[[File:2.1-Example-Story-Map.png|800px|frameless|center|link=|Example: Initial Story Map]]


rect 512 23 1335 207 [[AIoT_Business_Viewpoint|AIoT Business Viewpoint]]
The example shown here is the story map for the ACME:Vac product. It has six 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. Note that this story map does not include the entire mechatronic part of the system, including chassis, motor, locomotion (climbing over obstacles, etc.), home base, etc. Also, functional safety is not included here, which would be another real-world requirement.
rect 517 230 1337 409 [[AIoT_Usage_Viewpoint|AIoT Usage Viewpoint]]
rect 519 437 1337 614 [[AIoT_Data_and_Functional_Viewpoint|AIoT Data/Functional Viewpoint]]
rect 519 641 1345 818 [[AIoT_Implementation_Viewpoint|AIoT Implementation Viewpoint]]


rect 1360 171 1668 333 [[AIoT_Product_Viewpoint#ProductCanvas|Product Canvas]]
= Feature Team Mapping =
rect 1362 350 1668 527 [[AIoT_Product_Viewpoint#StoryMap|Story Map]]
One of the main challenges in almost all product organizations is the creation of 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, back end, testing, etc.), while product features usually require a mixture of these skills.
rect 1360 550 1666 723 [[AIoT_Product_Viewpoint#Backlog|Backlog]]


desc none
Consequently, the ''AIoT Playbook'' recommends an approach based on feature teams, which are assigned on demand to match the requirements of a specific feature. See [[Agile_AIoT_Organization|Agile AIoT Organization]] for a more detailed discussion. Feature teams can exist for longer periods of time, spanning multiple sprints, if the complexity of the feature requires this.
</imagemap>


== <span id="ProductCanvas"></span>Product Canvas ==
[[File:2.1-Example-US2Comp-Mapping.png|800px|frameless|center|link=|Mapping User Story to Components and Feature Team]]
[https://medium.com/qdivision/the-product-canvas-edf8df531 Roman Pichler] describes the product canvas as ''A simple but powerful tool that helps you create a product with a great user experience and the right features. It combines Agile and UX by complementing user stories with personas, storyboards, scenarios, design sketches and other UX artifacts. It’s designed to work with Scrum, Lean Startup, and Business Model Generation. The canvas supports Lean UX by combining user centered design and agile techniques.'' As can be seen in the diagram below, the proposed Ignite AIoT product canvas combines elements from the previously introduced viewpoints. Depending on the complexity of the AIoT solution, the product canvas will cover the entire solution, or only selected sub-products.
[[File:2.2-pv-ProductCanvas.png|600px|frameless|center|Product Canvas]]


== <span id="StoryMap"></span>Story Map ==
In the example shown here, the user story "Change cleaning mode" (part of the cleaning mode configuration feature) is analyzed.
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 results of the analysis show that a number of components on the robovac, the cloud and mobile app must be created or extended 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 this 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, who in the feature team plays the role of product (or feature) owner, as well as the scrum master, must be agreed upon.


[[File:2.2-pv-StoryMap.png|600px|frameless|center|Story Map]]
= Sprint Backlogs =
In preparation for each sprint, an individual sprint backlog must be created for each team, which is specific to the upcoming sprint. The sprint backlog is derived from the story map (essentially the product backlog). The sprint backlog contains only those items that are scheduled for implementation during that sprint. The sprint backlog can contain user stories to support features but also bug fixes or nonfunctional requirements.  


== <span id="Backlog"></span>Backlog ==
In larger organizations with multiple feature teams, the Chief Product Owner is responsible for the overarching story map, which serves as the product backlog. He prioritizes product backlog items based on risk, business value, dependencies, size, and date needed and assigns them to the individual teams. The teams will usually refine them and create their own sprint backlogs, in alignment with the Chief Product Owner and the product/feature owners of the individual teams.
The [https://en.wikipedia.org/wiki/Scrum_(software_development)#Product_backlog Scrum page] in Wikipedia defines the product backlog as ''a breakdown of work to be done and contains an ordered list of product requirements that a scrum team maintains for a product. Common formats include user stories and use cases. The requirements define features, bug fixes, non-functional requirements, etc.—whatever must be done to deliver a viable product. The product owner prioritizes product backlog items (PBIs) based on considerations such as risk, business value, dependencies, size, and date needed.''


Many modern development support tools like Jira support automatic visualization of the product backlog as a story map.
= Authors and Contributors =
{|{{Borderstyle-author}}
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}}
<br>
{{Designstyle-author|Image=[[File:Michael Hohmann.jpg|left|100px]]|author={{Michael Hohmann|Title=CONTRIBUTOR}}}}
|}

Latest revision as of 15:56, 29 March 2022

Business ViewpointUsage ViewpointData/Functional ViewpointImplementation ViewpointProduct ViewpointProduct ArchitectureAIoT 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 breakdown a larger body of work into specific work items using a hierarchical approach. Depending on the method applied, this hierarchy could include themes, epics, features, and user stories.

A story map organizes user stories in a logical way to present the big picture of the product. Story maps help ensure that user stories are well balanced, covering all important aspects of the planned solution at a similar level of detail. Story maps provide a two-dimensional graphical visualization of the Product Backlog. Many modern development support tools (such as Jira) support automatic visualization of the product backlog as a story map.

The AIoT Framework assumes 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
  • 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 may need 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, do not overlap, and cover 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 the perspective of the user.

Example: Initial Story Map

The example shown here is the story map for the ACME:Vac product. It has six 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. Note that this story map does not include the entire mechatronic part of the system, including chassis, motor, locomotion (climbing over obstacles, etc.), home base, etc. Also, functional safety is not included here, which would be another real-world requirement.

Feature Team Mapping

One of the main challenges in almost all product organizations is the creation of 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, back end, testing, etc.), while product features usually require a mixture of these skills.

Consequently, the AIoT Playbook recommends 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 periods of time, spanning multiple sprints, if the complexity of the feature requires this.

Mapping User Story to Components and Feature Team

In the example shown here, the user story "Change cleaning mode" (part of the cleaning mode configuration feature) is analyzed. The results of the analysis show that a number of components on the robovac, the cloud and mobile app must be created or extended 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 this 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, who in the feature team plays the role of product (or feature) owner, as well as the scrum master, must be agreed upon.

Sprint Backlogs

In preparation for each sprint, an individual sprint backlog must be created for each team, which is specific to the upcoming sprint. The sprint backlog is derived from the story map (essentially the product backlog). The sprint backlog contains only those items that are scheduled for implementation during that sprint. The sprint backlog can contain user stories to support features but also bug fixes or nonfunctional requirements.

In larger organizations with multiple feature teams, the Chief Product Owner is responsible for the overarching story map, which serves as the product backlog. He prioritizes product backlog items based on risk, business value, dependencies, size, and date needed and assigns them to the individual teams. The teams will usually refine them and create their own sprint backlogs, in alignment with the Chief Product Owner and the product/feature owners of the individual teams.

Authors and Contributors

Dirk Slama.jpeg
DIRK SLAMA
(Editor-in-Chief)

AUTHOR
Dirk Slama is VP and Chief Alliance Officer at Bosch Software Innovations (SI). Bosch SI is spearheading the Internet of Things (IoT) activities of Bosch, the global manufacturing and services group. Dirk has over 20 years experience in very large-scale distributed application projects and system integration, including SOA, BPM, M2M and most recently IoT. He is representing Bosch at the Industrial Internet Consortium and is active in the Industry 4.0 community. He holds an MBA from IMD Lausanne as well as a Diploma Degree in Computer Science from TU Berlin.


Michael Hohmann.jpg
MICHAEL HOHMANN, BSH HAUSGERÄTE GMBH
CONTRIBUTOR
Dr. Michael Hohmann works as a Systems Engineer in the field of autonomous cleaning robots at BSH. After studies in Mechanical Engineering and Measurement Science at TU Ilmenau he joined the Bosch Roxxter development team at BSH robotics department.