[almighty] Idea: modelling iterations

Todd Mancini tmancini at redhat.com
Mon Sep 26 13:50:52 UTC 2016


IMHO, iterations are 'intrinsic'. Moreover, when I think of the kinds of
operations that happen with iterations, those operations 'feel different'
than typical WI operations. For example:

1. I create a new 'user story' WI. It has no iteration.
2. A product owner 'approves'' the WI. Perhaps at this point in time,
assigns it to a release (where Release == parent iteration in a hierarchy
of iterations.)

E.g.
Release 23
   Sprint 165
   Sprint 166
   Sprint 167
   Sprint 168
Release 24
   Sprint 169
   Sprint 170
   ...

3. During sprint planning, WI gets pulled into a sprint (Say 166).
Iteration has changed again.
4. User story is NOT accepted at end of sprint, and, due to a new stack
ranking, is no longer considered for the release. Iteration is removed from
the WI.

All the while, many of those operations above will be done in a very fluid
way -- e.g., using a touch screen, the user story is dragged onto and off
of the various sprints.

As such, to me , that feels like an intrinsic operation on the user story
itself, and not some overly engineered technique to express iterations as
WI.

The agilista in me says "do it the simplest way possible to make it work.
Demo that. If future features require your initial implementation to
change, refactor." As such, my gut says: iterations are just a field on a
WI (probably *all* WIs, in fact). The data type of the field is
'iteration', it's hierarchical in nature, and the permissible values are
both end-user definable and unique for every project.

On Mon, Sep 26, 2016 at 6:31 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> On 26 Sep 2016, at 11:53, Thomas Mäder wrote:
>
> On 09/26/2016 11:07 AM, Max Rydahl Andersen wrote:
>>
>>> Yes, they could eventually grow into be generically defined but I think
>>> to start with we could start very basic - I for one do not think they
>>> should be munged into being work item/work item types at our API level. Not
>>> everything is a java.lang.Object either ;)
>>>
>> Actually, you're making my point: everything IS an instance of
>> java.lang.Object. so you can write
>>
>> Object foo= new Iteration();
>> foo.hashCode();
>>
>
> integers are not objects - they can be auto-casted in later versions.
>
> :)
>
> /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/20160926/305b6226/attachment.htm>


More information about the almighty-public mailing list