[almighty] modeling 'types' for planner work items

[Todd Mancini]

Global is fine. The actually ranking score is generally not displayed.
(i.e., you can artificially use integers when you display the list -- 1, 2,
3, 4, ...  even though the items may actually have values like 122.12,
123213.3431, 453353.8771, 453353.9222)

The risk of 'jumping' isn't that bad in actual practice.

On Thu, Sep 29, 2016 at 8:26 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> on the topic of ranking.
> Do you think of ranking as:
> a global one (basically a numerical value on each work item aka. Jira)
> that gets set relative to work items it is moved up and down between in
> the various queried lists.
> (This has the downside that the ranking is global, but also means a work
> item dependent on the
> query for a list suddenly can fall or jump a lot in the raking)
> or
> a local one (i.e. local for a "board"/milestone/iteration/etc. aka.
> GitHub/Trello model)
> Here a work item essentially has multiple rankings and it depends on what
> view you are looking
> at how the issues gets ordered.
> or
> maybe both are needed ?
> /max
>
> All of these item types can be on a 'backlog' -- it's just that there are
> many different backlogs, and different roles/responsibilities care about
> different things. In fact, a 'backlog' isn't really a concrete thing,
> inasmuch as it's really just a visualization of the data. (in other words,
> you can think of a backlog as a query).
>
> Essentially, a backlog is a query for one or more work item types,
> potentially filtered by some criteria, potentially arranged in a hierarchy,
> and generally sorted by a numerical valued field.
>
> e.g., what most engineers would consider to be a "product backlog" is a
> listing of all feature work item types, sorted by stack rank. Stack rank
> would be a numerical value, and lower values have a higher stack ranking.
>
> (So, feature X with stank rank 1 is higher in the backlog than feature Y
> with stank rank 10.)
>
> A sprint backlog would have both Features and Tasks, in a hierarchy, and
> would use filtering criteria to limit the results to the current sprint.
>
> But a product manager may be more concerned about the hierarchy of
> Scenarios and Value Propositions -- so that would be a different
> query, again sorted by 'stack rank' but potentially sorted by 'business
> value'.
>
> That's a very flexible solution to backlogs. But one problem with great
> flexibility is that new users don't know where to get started. This is why
> the "process templates" are important (e.g. the Agile process template or
> the Scrum process template, etc.). Not only do these templates define a set
> of work item types plus the relationships between those types, the
> templates should also be able to define some initial backlog views (which
> are, essentially, just queries). Ideally, the user has the flexibility to
> make their own backlog views, of course, but having process-appropriate
> backlog views whenever a new project is created would be key to usability.
>
>    -Todd
>
> On Thu, Sep 29, 2016 at 3:05 AM, Max Rydahl Andersen <manderse at redhat.com>
> wrote:
>
>>
>> Assuming that ‘fundamentals’, ‘value propositions’ and ‘experiences' will
>>> exist as part of the backlog. As the experiences get converted to epics,
>>> user stories and these user stories move to completion (visualizing it
>>> as a
>>> Kanban board), we will need to come up with a mechanism to move the
>>> associated ‘fundamentals’, ‘value propositions’ and ‘experiences' of of
>>> the
>>> backlog as well. As we should only have unfinished work as part of the
>>> backlog.
>>>
>>> Since the behavior of some of these types of work items will be
>>> different,
>>> do we need to build in logic associated with ‘type’ of work item? For
>>> example would ‘value propositions’ or ‘experiences’ have a state
>>> associated? If yes, would it  get incrementally updated along with each
>>> of
>>> child work item?
>>>
>>
>> Yes, work items have a state - but what is the incremental updated you
>> refer to ?
>>
>> Do you mean to be able to see the progress ? Then I would reckon that is
>> best shown
>> by visualising the parent/child relationships - i.e. 4 out of 10
>> "child"/contained-tasks
>> are done.
>>
>> That would work well for experiences especially.
>>
>> For ever running things like Fundamentals I don't follow why you would
>> see those ever getting
>> removed from "a board" or even backlog.
>>
>> They are inherently always there and not really in the backlog - but used
>> for categorising the
>> items in the backlog.
>>
>> /max
>> http://about.me/maxandersen
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>
> /max
> http://about.me/maxandersen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160929/c2048422/attachment.htm>