[almighty] modeling 'types' for planner work items

[Ranjith Varakantam]

On Fri, Sep 30, 2016 at 1:22 AM, Leonard Dimaggio <ldimaggi at redhat.com>
wrote:

> Ranjith,
>
> When you say:
> '...If yes, would it  get incrementally updated along with each of child
> work item?...'
>
> Are you referring to a state change in a child element resulting in an
> automatic state update in its parent element?
>

>> Yes, for example a user story has 4 tasks, when these tasks are
complete, the user story should automatically be  marked complete. The same
would hold good for experience, if the user stories related to the user
stories are complete then the experience state should also change.

>> This would also inline with the query based results that Todd suggested,
because when I am refining the backlog, I only want to see the experiences
or user stories that are yet to be worked on. i.e. the ones which are not
completed.


>
> -- Len
>
>
> 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
>>
>
>
>
> --
> 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
>
>
>


-- 
Ranjith Reddy V.
Agile Coach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160930/781ed6a5/attachment.htm>