AIoT Product Viewpoint: Difference between revisions

Line 20: Line 20:
== <span id="StoryMap"></span>Story Map ==
== <span id="StoryMap"></span>Story Map ==
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.
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.
[[File:2.2-pv-StoryMap.png|600px|frameless|center|Story Map]]


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.''
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.''

Revision as of 22:46, 9 July 2021

Business ViewpointUsage ViewpointData/Functional ViewpointImplementation ViewpointProduct ViewpointProduct ArchitectureAIoT Product Viewpoint

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

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 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.

The most common way for a Scrum team to express features on the agile product backlog is in the form of 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.

Many modern development support tools such as Jira support automatic visualization of the product backlog with user stories as a story map.

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.

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.

Example: Initial Story Map

Feature Team Mapping

Mapping User Story to Components and Feature Team