[almighty] modeling 'types' for planner work items

[Max Rydahl Andersen]

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/efda8612/attachment.htm>