[almighty] Clarification around Types

Leonard Dimaggio ldimaggi at redhat.com
Thu Jan 26 13:48:18 UTC 2017 

Questions/Comments on the diagram:

Team Hierarchy

   - Teams contain 1..n people (each person can be on 1..n teams) and
   provide user perms
      - Each team can be associated with 1..n areas

Organization Hierarchy

   - Spaces (formerly called "projects"), each space contains one backlog
      - Areas - hierachical, expressed in paths
      - Iterations (can also have child iterations)

Planning Hierarchy

   - Epics
      - Stories
         - Tasks

Execution Hierarchy

   - Release (can also have child releases)
      - Iterations (can also have child iterations)
         - Sprints

Open Questions:

   - Can teams be hierarchical?
   - Are releases a type of iteration?

Thx!



On Mon, Jan 23, 2017 at 4:39 PM, Adam Jolicoeur <ajolicoe at redhat.com> wrote:

> Hi Everyone,
>
> As part of this conversation, I thought it would make sense to share the
> Areas diagram that UX has created, through discussions with Todd and
> Michael V. Additional information can be found on GitHub:
> https://github.com/fabric8io/fabric8-ux/issues/101.
>
> -Adam
>
> On Jan 23, 2017, 4:06 PM -0500, Michael Virgil <mvirgil at redhat.com>,
> wrote:
>
> The intent is as Konrad describes.
>
> Based on the current behavior, there are some issues that can be addressed
> in the design/implementation to make this clearer. Would also need to
> ensure that the context and providing what can be created within that
> context from the backend. UX team is currently working on refining the
> UX/interaction to clarify this user experience - in this area.
>
> In general; the process template selected when creating the Space defines
> the process hierarchy (planning work Item relationships, among other
> things).
>
> The intent:
>
>    - The quick create, should be just that, quickly create goal based
>    work items at a level that I've determined by my setting my context
>    - The context; where I am working within the hierarchy; Theme,
>    Initiative, Epic, Story, Task... Vision, Scenario, Value Prop, Experience,
>    Feature, Task... or whatever
>    - User Experience needs to be clean, clear and obvious to the user
>
> I should be able to set my context and then...
>
>    - Create a bunch of tasks for a story...
>    - Create a bunch of stories to refine the goal of an Epic...
>    - Create a bunch of stories in the backlog...
>    - Create a bunch of initiatives while brainstorming...
>    - etc.
>
> It would be easy to envision a common set of filters/views/tree structures
> that would be applied to all these hierarchies. The look and feel would be
> the same and comfortable for parent/child relationships - defined in the
> process template. Should not need any custom code in the backend or FE to
> accommodate these process templates. If we focus on Agile/Scrum for the
> first implantation using the templates, I would assume adding Waterfall,
> Red Hat or other process would not be a major feat...
>
> I would also anticipate that the process template would allow a team over
> time, not out of the gate, to define the policies, rules and/or constraints
> of the process. This could include the rules/policies for work items
> (parent/children) relationships, iterations (milestones), policies for
> permissions, or even the fields to present on views. I think there is a lot
> we could configure and potentially allow to be defined within the template.
>
> Just some things we need to think about.
>
> For now, lets just get a simple end-2-end use case for the parent/child
> hierarchy working using a process template and we can extend it over time.
>
> Michael
>
> On Mon, Jan 23, 2017 at 8:36 AM, Aslak Knutsen <aslak at redhat.com> wrote:
>
>> If that's the same QuickAdd bar, then I think it should visually be moved
>> inside the Open WI draw to show the context things are being added and the
>> 'type selector' be filtered same as 'allowed links'.
>>
>> -aslak-
>>
>> On Mon, Jan 23, 2017 at 2:23 PM, Konrad Kleine <kkleine at redhat.com>
>> wrote:
>>
>>> Aslak,
>>>
>>> yes we need something superior, but if the quick add bar simply performs
>>> two actions rather than one, we're safe:
>>>
>>> 1. Add work item (userstory)
>>> 2. Link to currently "open" work item (epic)
>>>
>>> That implies three things (at least)
>>>
>>> 1. we can have some form of navigation that makes allows for filtering
>>> user stories based on a concrete link type (e.g. child of)
>>> 2. the quick add bar knows about which link type can be used (maybe the
>>> one which was used to filter in the first place?)
>>> 3. the quick add bar adds the new work item (userstory)
>>> 4. the quick add bar creates the link between the epic (currently
>>> filtered on) and the newly created user story
>>>
>>>
>>>
>>> On Mon, Jan 23, 2017 at 2:08 PM, Aslak Knutsen <aslak at redhat.com> wrote:
>>>
>>>> That workflow is unrelated to 'Epics'.
>>>>
>>>> It's what we do in every planning sessions on some level.
>>>>
>>>> Create/Read a userstory, add 10 tasks.
>>>>
>>>> It's a feature for, I create/have a parent, now create n children.
>>>>
>>>> We need a better approach than;
>>>>
>>>> * Create parent
>>>> * Create child 1
>>>> * Create child 2
>>>> * Create child n
>>>> ...
>>>> * Open parent
>>>> * Search and Link child 1
>>>> * Search and Link child 2
>>>> * Search and Link child n
>>>> ...
>>>>
>>>>
>>>> -aslak-
>>>>
>>>> On Mon, Jan 23, 2017 at 1:58 PM, Konrad Kleine <kkleine at redhat.com>
>>>> wrote:
>>>>
>>>>> If I were a user of the system I'd probably go in and
>>>>>
>>>>>
>>>>>    1. create an epic from the work item type dialog.
>>>>>    2. go to the quick add and add 10 features
>>>>>
>>>>> IMHO we shouldn't first build for custom tailored UI solutions that
>>>>> fit a work flow specific to epics. I'm not saying we shouldn't do this at
>>>>> all but if we have the tools in place to do operate generically, then this
>>>>> is good start, no?
>>>>>
>>>>> On Mon, Jan 23, 2017 at 1:51 PM, Todd Mancini <tmancini at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Can someone describe to me the experience of this common usage
>>>>>> pattern: a user wants to create a new Epic and ten related Features. What's
>>>>>> that workflow for that?
>>>>>>
>>>>>> On Mon, Jan 23, 2017 at 7:39 AM, Konrad Kleine <kkleine at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> We currently have the a little icon next to the left most field once
>>>>>>> you've clicked the quick add button. I suggest to make this a toggle just
>>>>>>> like we used to have it for the work item symbol in the top left corner of
>>>>>>> the details page: https://cloud.githubuserconten
>>>>>>> t.com/assets/193408/21686784/d717829e-d366-11e6-9641-b61cece
>>>>>>> 54c99.png. Currently this is just a symbol and no longer a menu.
>>>>>>>
>>>>>>> On Mon, Jan 23, 2017 at 1:26 PM, Aslak Knutsen <aslak at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Then what happens to QuickAdd when there are multiple types shown
>>>>>>>> in a list?
>>>>>>>>
>>>>>>>> On Mon, Jan 23, 2017 at 1:21 PM, Konrad Kleine <kkleine at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hey Aslak,
>>>>>>>>>
>>>>>>>>> > The QuickAdd feature is currently hard coded to add items of
>>>>>>>>> type 'UserStory'. With no fixed types and no option to change the type this
>>>>>>>>> looks wrong.
>>>>>>>>> > Should the Process Definition have some option to define a
>>>>>>>>> 'default' Type that should be used here?
>>>>>>>>> > Should the Quick Add have an option to select which type it
>>>>>>>>> should quick add? Optionally, should the Quick Add remember the users
>>>>>>>>> previously used type? Or
>>>>>>>>> > possible types based on some form of role, e.g. PM's would most
>>>>>>>>> likely create Experiences, SM UserStories and Devs Tasks?
>>>>>>>>>
>>>>>>>>> As far as I understood UI and UX, they want to make the quick add
>>>>>>>>> bar context sensitive. So when you're viewing a list of user stories, the
>>>>>>>>> quick add will just add user stories. But if you're viewing a list of
>>>>>>>>> epics, the quick add shall add epics. I have no clue about the technical
>>>>>>>>> realization yet but that's at least what I heard from talking to different
>>>>>>>>> people. It seems the most convenient to me instead of having some process
>>>>>>>>> defining what you can quick add.
>>>>>>>>> The only problem I see is how to get the "context", e.g. how to
>>>>>>>>> know that the list of work items is currently just showing features, epics
>>>>>>>>> or user types. Shall this be done with filters or maybe implicit filters?
>>>>>>>>>
>>>>>>>>> - Konrad
>>>>>>>>>
>>>>>>>>> On Mon, Jan 23, 2017 at 12:08 PM, Aslak Knutsen <aslak at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> A few points to clear up around the generic type system.
>>>>>>>>>>
>>>>>>>>>> 'Epic'
>>>>>>>>>>
>>>>>>>>>> In the UX designs, Epic is special, e.g. it shows up as summary
>>>>>>>>>> points in the same draw as Iterations and can be created directly from the
>>>>>>>>>> 'right-click' menu: https://redhat.invisiona
>>>>>>>>>> pp.com/share/QU9U8D8GF#/screens/212141138
>>>>>>>>>>
>>>>>>>>>> What is the generic term/feature for this? Is the intent to be
>>>>>>>>>> able to define as part of the Process Template which Type should be the
>>>>>>>>>> 'special/top' type? What is the equivalent type in the PDD style,
>>>>>>>>>> Vision/Experience?
>>>>>>>>>>
>>>>>>>>>> Part of https://github.com/fabric8io/fabric8-planner/issues/657
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 'WorkItem Links hierarchy'
>>>>>>>>>>
>>>>>>>>>> Same as a Feature can be a Child of an Experience, a UserStory is
>>>>>>>>>> a Child of an Epic. What are the Link Forward and Reverse names for this
>>>>>>>>>> relationship?
>>>>>>>>>>
>>>>>>>>>> Relates to? Belongs to? Child of? Part of?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 'Quick Add'
>>>>>>>>>>
>>>>>>>>>> The QuickAdd feature is currently hard coded to add items of type
>>>>>>>>>> 'UserStory'. With no fixed types and no option to change the type this
>>>>>>>>>> looks wrong.
>>>>>>>>>>
>>>>>>>>>> Should the Process Definition have some option to define a
>>>>>>>>>> 'default' Type that should be used here?
>>>>>>>>>> Should the Quick Add have an option to select which type it
>>>>>>>>>> should quick add? Optionally, should the Quick Add remember the users
>>>>>>>>>> previously used type? Or possible types based on some form of role, e.g.
>>>>>>>>>> PM's would most likely create Experiences, SM UserStories and Devs Tasks?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> PM's input appreciated.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -aslak-
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> almighty-public mailing list
>>>>>>>>>> almighty-public at redhat.com
>>>>>>>>>> https://www.redhat.com/mailman/listinfo/almighty-public
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
>


-- 
Len DiMaggio (ldimaggi at redhat.com)
JBoss by Red Hat
314 Littleton Road
Westford, MA 01886  USA
tel:  978.392.3179
cell: 781.472.9912
http://www.redhat.com
http://community.jboss.org/people/ldimaggio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20170126/91d05971/attachment.htm>

More information about the almighty-public mailing list