[almighty] modeling 'types' for planner work items

[Monica Granfield]

+1 here on this approach

On Fri, Sep 30, 2016 at 9:35 AM, Todd Mancini <tmancini at redhat.com> wrote:

> I'll go on the record as saying that I once helped create a system whereby
> child tasks could automatically update parent tasks -- for example: "all
> the children are done, so mark the parent as done."
>
> It was a terrible, terrible mistake.
>
> Yes, on paper, it looks like the right thing to do. In reality, reality is
> much, much different. For very strict, waterfall processes, it can
> sometimes work. But that assumes you've got a completely well-defined,
> repeatable and essentially unchanging process. (e.g. an assembly line or a
> process you manage with a Gantt chart). But, outside of that scope, it
> rarely works well.
>
> e.g. consider a value prop broken down into experiences to be accomplished
> over the next 6 months. Assume all of the experiences are completed. Is the
> value prop now 'done/realized'? Maybe it is, but maybe it is not (or at
> least not fully). Maybe to fully realize the value prop requires three 6
> month seasons of experiences. In other words, just because I have 4
> children now doesn't mean I won't have additional children later. The
> closing out of the value prop is really a human decision, not an
> algorithmic one.
>
> Will some people want automatically closing parents? Probably. Should we
> have that as an option? Maybe, but not for Pizza the Hutt. Many, many
> popular systems are surviving without this feature and happy users. The
> unhappy ones can go use IBM DOORS or something like that. :)
>
> Note that it may be valuable to *highlight* any such inconsistencies --
> e.g., some form of UI that draws my attention to an open parent with all
> children closed, or a report that lists all such WIs for me. That may help
> me to identify things on which I should make a decision.
>
>    -Todd
>
> On Fri, Sep 30, 2016 at 2:12 AM, Max Rydahl Andersen <manderse at redhat.com>
> wrote:
>
>> On 30 Sep 2016, at 7:24, Ranjith Varakantam wrote:
>>
>> 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 assumes you have captured *everything* in all tasks and upfront
>> knows nothing else are there.
>>
>> I would not think automatic changing state to complete is the right thing
>> to do.
>>
>> Being able to list issues which have all their children and dependent
>> issues resolved so
>> one can make an explicit decision - *thats* useful.
>>
>> 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.
>>
>> Yup - but that query should be done by query and stories going into the
>> state of being in progress,
>> not about amount of child tasks it has IMO.
>>
>> /max
>> http://about.me/maxandersen
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161004/727e8e35/attachment.htm>