Uploaded image for project: 'SAFe Program'
  1. SAFe Program
  2. SP-2359

spike for new widgets in Taranta

Change Owns to Parent OfsSet start and due date...
    XporterXMLWordPrintable

Details

    • Obs Mgt & Controls
    • Hide

      A report describing:

      • a series of validated UI mockups showing how each widget should appear and behave
      • the mockups are validated in the sense that they incorporate the feedback collected from prospective SKA users (members of other teams) based on interviews and informal user testing sessions
      • a description of each widget in terms of WHO/WHEN/WHAT/WHY (as mentioned above).

      It should be possible to estimate the effort needed to implement each of those widgets.

      The negotiable part of this enabler is in the set of considered widgets, to be taken in the order listed in the "description" field.

      Show
      A report describing: a series of validated UI mockups showing how each widget should appear and behave the mockups are validated in the sense that they incorporate the feedback collected from prospective SKA users (members of other teams) based on interviews and informal user testing sessions a description of each widget in terms of WHO/WHEN/WHAT/WHY (as mentioned above). It should be possible to estimate the effort needed to implement each of those widgets. The negotiable part of this enabler is in the set of considered widgets, to be taken in the order listed in the "description" field.
    • 4
    • 4
    • 40
    • 10
    • Team_CREAM
    • Sprint 3
    • Hide

      Proposed by the Feature Owner number of widgets was created.
      They provided the new functionality for SKAO users such as:

      • configurable
      • condition-related
      • compact.

      Source of data:

      • was coming from SKAO users` feedback, based at the previous user research sessions
      • was SKAO usage relevant.

      Desirability of the new widgets - their usage was justified by the SKAO user`s needs , according hierarchy of values:

      • want-have/ must-have.

      +Risk assessment +on the new widgets implementation was done.
      FP were defined for each widget, according level of their complexity.

      Complications were taken into consideration such as:

      • how often such widhet will be used and if not ofte & widget is complex, does it wirth to create it
      • does Taranta environment supports implementation of these widgets and if yes:
        fully or additional libraries will be required (Plottly library was considered, for example)?

      Complications & challenges - should be taken into consideration.
      +Effort estimation +(time, complexity) - should be calculated.

      Purpose of the widgets` requirements was served: team captured stakeholders needs.

      Key results were summarised & documented for sharing with the SKAO team.
      Also were presented at the System demo session with FO J.Brajnik (26.04.2022).
      His feedback was achieved & analysed for the upcoming use cases to improve our approach to the similar tasks in the future.

      Document

      Updated version attached.

      Presentation links

      no animation:
      https://docs.google.com/presentation/d/1KGzNY3Ew3AIk8SH65cA8OEE17zpDYiCb/edit

      with animation:
      https://docs.google.com/presentation/d/1JUraklFw4Yp6tKgjY8TKwncghoSxlkMu/edit

      Show
      Proposed by the Feature Owner number of widgets was created. They provided the new functionality for SKAO users such as: configurable condition-related compact. Source of data: was coming from SKAO users` feedback, based at the previous user research sessions was SKAO usage relevant. Desirability of the new widgets - their usage was justified by the SKAO user`s needs , according hierarchy of values: want-have/ must-have. +Risk assessment +on the new widgets implementation was done. FP were defined for each widget, according level of their complexity. Complications were taken into consideration such as: how often such widhet will be used and if not ofte & widget is complex, does it wirth to create it does Taranta environment supports implementation of these widgets and if yes: fully or additional libraries will be required (Plottly library was considered, for example)? Complications & challenges - should be taken into consideration. +Effort estimation +(time, complexity) - should be calculated. Purpose of the widgets` requirements was served: team captured stakeholders needs. Key results were summarised & documented for sharing with the SKAO team. Also were presented at the System demo session with FO J.Brajnik (26.04.2022). His feedback was achieved & analysed for the upcoming use cases to improve our approach to the similar tasks in the future. Document Updated version attached. Presentation links no animation: https://docs.google.com/presentation/d/1KGzNY3Ew3AIk8SH65cA8OEE17zpDYiCb/edit with animation: https://docs.google.com/presentation/d/1JUraklFw4Yp6tKgjY8TKwncghoSxlkMu/edit
    • 14.6
    • Satisfies Acceptance Criteria, Accepted by FO

    Description

      We need to run a UX spike (a spike aimed at understanding WHO will use something, under WHICH circumstances, to drive WHAT decisions or actions, and WHY those are needed) to better understand usefulness of these widgets:

      • active dashboards: given N dashboards, each of them is associated to some condition (like an event being signalled) that would automatically make that dashboard the visibile one.
      • active widgets: in a dashboard, a widget could be normally hidden or collapsed. When an event occurs then the state of the widget changes.
      • cyclic dashboards: given N dashboards, the user can link them in a loop so that when run, taranta shows each dashboard for a given time and then switches to the next. Or the switch is manually triggered.
      • a barchart widget, where different variables can be plot and compared. Similar to the barchart of R.
      • widget for presenting tabular info (eg each rows represent an antenna, a subarray, a beam, ...; with associated attributes and even buttons + LEDs)
      • tabbed dashboards: see the description in SP-1871
      • starburst diagram: see the description in SP-1870

       NOTE

      I suggest that this work is tackled in a Lean UX approach: the build-measure-learn loop.

      • build mockups based on current ideas
      • measure: collect feedback with interviews and user testing sessions
      • learn: what might work, what might be useful, what might be challenging from a usability viewpoint

      This loop should be executed at least twice for each widget.

      Attachments

        Issue Links

          informs

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-2508 Taranta widgets can be collapsed/expanded

          • Should have - Items labelled as "Should have" are important but not necessary for delivery in the current delivery timebox. While "Should have" items can be as important as "Must have", they are often not as time-critical or there may be another way to satisfy the requirement so that it can be held back until a future delivery timebox.
          • Funnel

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-2507 Taranta has a barchart widget

          • Won't have (this time) - Items labelled as "Won't have", have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, "Won't have" items are not planned into the schedule for the next delivery timebox.
          • Funnel

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-2506 Taranta has a tabular view

          • Should have - Items labelled as "Should have" are important but not necessary for delivery in the current delivery timebox. While "Should have" items can be as important as "Must have", they are often not as time-critical or there may be another way to satisfy the requirement so that it can be held back until a future delivery timebox.
          • Done
          is required by

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-1870 starburst diagram

          • Could have - Items labelled as "Could have" are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit.
          • Funnel

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-1871 tabbed dashboards

          • Could have - Items labelled as "Could have" are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit.
          • Funnel
          mentioned in

          Page Loading...

          Page Loading...

          Page Loading...

          Page Loading...

          Page Loading...

          Page Loading...

          Page Loading...

          Page Loading...

          Page Loading...

          Structure

            Activity

              People

                g.brajnik Brajnik, Giorgio
                g.brajnik Brajnik, Giorgio
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (100.00%)

                  Feature Estimate: 4.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete2232.0
                  Total2232.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel