[almighty] modeling 'types' for planner work items

[Todd Mancini]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160929/17300110/attachment.htm>