<div dir="ltr"><div><br></div><div>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:</div><div><br></div><div>1. I create a new 'user story' WI. It has no iteration.</div><div>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.)</div><div><br></div><div>E.g.</div><div>Release 23</div><div>   Sprint 165</div><div>   Sprint 166</div><div>   Sprint 167</div><div>   Sprint 168</div><div><div>Release 24</div><div>   Sprint 169</div><div>   Sprint 170</div><div>   ...</div></div><div><br></div><div>3. During sprint planning, WI gets pulled into a sprint (Say 166). Iteration has changed again.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 <b>all</b> 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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 26, 2016 at 6:31 AM, Max Rydahl Andersen <span dir="ltr"><<a href="mailto:manderse@redhat.com" target="_blank">manderse@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div class="gmail-HOEnZb"><div class="gmail-h5">On 26 Sep 2016, at 11:53, Thomas Mäder wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
On 09/26/2016 11:07 AM, Max Rydahl Andersen wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
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 ;)<br>
</blockquote>
Actually, you're making my point: everything IS an instance of java.lang.Object. so you can write<br>
<br>
Object foo= new Iteration();<br>
foo.hashCode();<br>
</blockquote>
<br></div></div>
integers are not objects - they can be auto-casted in later versions.<br>
<br>
:)<br>
<br>
/max<br>
<a href="http://about.me/maxandersen" target="_blank" rel="noreferrer">http://about.me/maxandersen</a><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" target="_blank" rel="noreferrer">https://www.redhat.com/mailman<wbr>/listinfo/almighty-public</a><br>
</div></div></blockquote></div><br></div></div>