[almighty] modeling 'types' for planner work items

[Todd Mancini]

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