Create Iteration for a Space

[michaelkleinhenz]

Precondition Note: to make definitions clearer: Iterations are not Sprints! Iterations can be used to model the sprint concept, but are a general concept to be able to model larger or different concepts. This is also the reason why dates are optional.

Description

As a user, I can create an iteration for a space.

Functional Acceptance Criteria

1. The user can create an iteration from a dialog.
2. Creating an iteration requires a title (alphanumeric value), an optional start date (date) and an optional end date (date).
3. It is not possible to create an iteration with an empty title.
4. Iterations are tied to spaces.

Note: Iterations are tied to spaces but could later contain work items from foreign spaces as well. This is not a direct functional requirement, but a hint for design decisions.

Note: Iterations are not owned by a user in the final system. There must be some authZ scheme in place that controls who can modify the iteration base data (title, dates). For now, the owner of the spaces enclosing the iteration has write access to the iteration data. Also, orgs are out of context for this story.

Note: Iterations are hierarchial, an iteration can be a "sub-iteration". This is not represented in this story, but mentioned as input for design decisions.

Non-functional Acceptance Criteria

1. The "create iteration" view is easily accessible from anywhere in the system UI.
2. The result of the implementation of this story should also be a basic data model and a concept for organizing iterations and other dependent entities.

Dependencies

1. Userstory Update an Iteration #410
2. Userstory Close an Iteration #411
3. Userstory Set/Update Iteration on Work Items #412

Wireframes

https://redhat.invisionapp.com/share/KA9CAYL7M from the comment.

[michaelkleinhenz]

The model req's for iterations may be complex. Open Questions are:

• is Iteration:Work Items an 1:n relation?
• what happens to work items on closing an iteration? (see Close an Iteration #411)

[michaelkleinhenz]

Chatlog:
[6:24 PM] Max Rydahl Andersen: okey so when you say workitems are in an iteration you don't mean all types ?
[6:24 PM] Max Rydahl Andersen: in VSO they put epics into the higher level iterations which makes the querying and navigation pretty nice.
[6:26 PM] Michael Kleinhenz: @maxandersen maybe. That would be a rule contained in the WIT, WILT definitions (or surrounding them).
[6:27 PM] Max Rydahl Andersen: @michaelkleinhenz that sounds overly complicated imo.
[6:27 PM] Michael Kleinhenz: So I would define that in base-level iterations, any work item can be part of it. Restricting that would be a part of a "usage scheme".
[6:28 PM] Michael Kleinhenz: So, like you can define what WIT and WILT are available, you can also define which behaviours are available for them.
[6:29 PM] Michael Kleinhenz: Or maybe this is an implicit part of trhe definition of WILTs.
[6:30 PM] Michael Kleinhenz: If I think about that more, I am thinking this is the case, the WILT defines exactly what can be linked together. And there may be a setup that simply does not allow (because there is no WILT) to put "Epics" WIs into iterations.
[6:31 PM] Michael Kleinhenz: And that is also a very basic question: are iterations WIs? Or are iterations something basic that exists on the same level as WITs? I asked that before and the answer was "Iterations" are atomic elements.
[6:32 PM] Michael Kleinhenz: But anyway, thats all only discussions about later (or basic) implementation. For now, we have iterations 1:n to work items. Not more.

[nimishamukherjee]

Iterations are owned by the user that created the iteration.

@michaelkleinhenz the project owner could also be an iteration owner?

[qodfathr]

I don't see a need for iterations to be 'owned' by anyone. They are part of a project, and there will eventually be a permission model which determines who can do what to an iteration.

Both start dates and end dates should be optional for iterations.

[michaelkleinhenz]

@qodfathr on the owner: I removed the req from the story, but this introduces some uncertainty in the implementation at the current state. The team will surely ask who will be in the current state be allowed to edit the title. As we don't have the authZ scheme in place, whou would that be? Maybe everyone, but that contradicts that we are currently introducing owners and very basic "owner-only" permissions into the system. Can you clarify on that problem?

On the date: are you sure? Omitting dates from the iteration I think removes the basic meaning of iterations, degrading them to just a list of WIs..equivalent to a simple keyword/tag or category.

[michaelkleinhenz]

@maxandersen @qodfathr suggestion: Iterations can be contained in iterations (or in other words, iterations are hierarchical). That makes sense. The goal for this story (and every story, for that matter) is, to keep it reasonably small while not restricting someting that comes later or creating throwaway code.

So, I would for this story restrict the contents of iterations to work items and add a later story to allow Iterations being added to Iterations (or let the user CRUD a hierarchical iteration model). I would note that on the story to give hints for design decisions.

The reasoning behind my suggestion is more about the UI req's than for the core req's here. The core might provide hierarchical iterations easily, but for the UI this would be a different beast. Not necessarily very complex, but definitely beyond something that should all be crammed into one single story.

[qodfathr]

@michaelkleinhenz Yes, I'm very sure that dates should be optional.

Iterations are hierarchical -- that was the plan. Users will generally interact with them as paths. e.g., "Release 1/Sprint 4".

An iteration is just a special data type (essentially a path with a predefined set of paths available), and all work items have a single iteration field of this data type.

In a large project, there can be multiple, overlapping iterations. e.g, imagine the following:

Foo
Release 3
Sprint 1 [1-Jan-2017 - 14-Jan-2017]
Sprint 2 [15-Jan-2017 - 28-Jan-2017]
Bar
Carnation Release
Sprint 131 [1-Jan-2017 - 21-Jan-2017]
Sprint vNext [22-Jan-2017 - ]

As you can see, Foo/Release 3/Sprint 1 runs at the same time as Bar/Carnation Release/Sprint 131, although they do not end of the same date. Moreover, Sprint vNext is currently open-ended with no end date. Also, none of the intermediate 'nodes' (e.g. Bar, Carnation Release, etc.) have any dates, although they are all valid iterations (i.e. a WI may be assigned to "Bar" or "Foo/Release 3")

In cases like this, the notion of a 'Team' is important. Typically, in this overlapping world, Teams are 'rooted' at an intermediate iteration node. e.g., Team A may have its default iteration set to "Foo/Release 3" and Team B is set to "Bar/Carnation Release." This helps to determine which iterations are then generally exposes in the UI (although members of the team can assign WIs to any iteration, even ones outside of their default parent).

Lastly, on ownership -- iteration definitions are basically part of the overall project definition, so, absent of a permission model, just limit the CRUD of iteration definitions to the project creator for now.

[michaelkleinhenz]

@qodfathr ok, updated the story.

[Mgranfie]

Thanks all, this is a helpful discussion. Dates on iterations seem to be
more of a preference and way to work. Smaller groups or companies, personal
preference on how to run a team. I would agree that having them as optional
will be our best approach.

I agree with Todd, that permissions would set and control who can edit the
Iteration.

-Monica

On Mon, Oct 31, 2016 at 8:03 AM, Michael Kleinhenz <notifications@github.com

wrote:

@qodfathr https://github.com/qodfathr ok, updated the story.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#409 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARTwq26R7JkTBB5Exd1FOBKLttclCwEXks5q5dj_gaJpZM4Kid1Y
.

[ldimaggi]

With regard to iteration ownership:
Will each project have an owner? Wouldn't the project owner also always be the owner of each iteration by default?

[Mgranfie]

This is the impression I have....

On Mon, Oct 31, 2016 at 2:38 PM, Len DiMaggio notifications@github.com
wrote:

With regard to iteration ownership:
Will each project have an owner? Wouldn't the project owner also always be
the owner of each iteration by default?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#409 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARTwq4wVjQmDetlL5aWj9VDlXdgZXiXWks5q5jXBgaJpZM4Kid1Y
.

[michaelvirgil]

I'm not sure I understand the need (or concept) of an iteration or a Sprint
ownership... it is a milestone - time-boxed increment of planned work. It
has context and meaning within a project... if there is any ownership, it
is the team has ownership of the Sprint plan measured in that time-boxed
iteration, a commitment within the context of the project...

Michael

On Mon, Oct 31, 2016 at 2:56 PM, MonicaGran notifications@github.com
wrote:

This is the impression I have....

On Mon, Oct 31, 2016 at 2:38 PM, Len DiMaggio notifications@github.com
wrote:

With regard to iteration ownership:
Will each project have an owner? Wouldn't the project owner also always
be
the owner of each iteration by default?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#409
issuecomment-257381651>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
ARTwq4wVjQmDetlL5aWj9VDlXdgZXiXWks5q5jXBgaJpZM4Kid1Y>

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#409 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK_m9nqdX_4DUh7deu99gMJ7QEkFSY91ks5q5jn4gaJpZM4Kid1Y
.

[Essjaysee]

@maxandersen @michaelkleinhenz What are WITs and WILTs?

[maxandersen]

WIT = Work Item Types
WILT = Work Item Link Types

[maxandersen]

@michaelvirgil and @ldimaggi I believe the "ownership" @qodfathr and @michaelkleinhenz refer to here is not about who is assigned/owning it but who have permissions to create/delete/update iterations. And suggestion is for simplicty sake for now just have it that the one who created a project can do so.

This of course become problematic if we introduce organization - but until we have that keeping it simple.

[michaelkleinhenz]

@michaelvirgil @ldimaggi as @maxandersen said, the ownership defined here is just about modifying the iteration's data like title, dates etc... As we are intruducing basic authZ now in other stories, it makes sense to define who are allowed to make changes to this data.

[qodfathr]

We probably should start a document outlining all of the various permissions we eventually need to model, and the level at which they exist. We can then prioritize which ones we want to implement.

e.g.

Org Level Permissions
Create public projects
Create private projects
Assign permissions to non-organizational users in a private project
etc.

Project Level Permissions
Create new iterations
Modify existing iterations
Assign permissions to non-organizational users
Switch public project to private
Switch private project to public
etc.

[michaelkleinhenz]

@qodfathr sounds like an epic or at least an architectural runway story to me.

[Mgranfie]

@michael Kleinhenz +! and this needs to be conceptually laid out as well.

On Mon, Nov 7, 2016 at 5:22 AM, Michael Kleinhenz notifications@github.com
wrote:

@qodfathr https://github.com/qodfathr sounds like an epic or at least
an architectural runway story to me.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#409 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARTwq57lc7_ei4XsmRl4djgG7M6XIbjrks5q7vvKgaJpZM4Kid1Y
.

[Essjaysee]

A few questions @maxandersen @michaelkleinhenz @Mgranfie @qodfathr @michaelvirgil

1. If date is optional, the user would need to specify when creating the iteration that it is to be 'current' or 'future', right?
2. Does an iteration only become 'past' once it is closed?
3. How do we imagine the list of future iterations being ordered without dates? Another field where you'd indicate its order in the list? Drag and drop on the iteration list? Simply the order of creation without an option to reorder them?
4. I'm guessing we will allow for multiple current iterations?

[michaelkleinhenz]

@Essjaysee I think an iteration might just not have any time fixture at all. In general, iterations may be sprints, but may also be something completely different. Iterations are on the backside of the system just a group of work items plus some metadata. Sprints are just modelled using iterations.

Also, coming back to actual sprints, I think it would make sense to allow users to create a sprint just by adding work items and not giving any start or end date.

[michaelkleinhenz]

@Essjaysee on the sorting of iterations: interesting problem, I don't have a solution for that yet. But thats also not part of this story. Currently, new iterations are just appearing in dropdowns on different views once created.

But this might be missing from #410, because in order to change the metadata of an iteration, the user has to select it somehow.

[michaelkleinhenz]

@Essjaysee on multiple iterations: yes, we will have multiple concurrent iterations.

[Mgranfie]

We should provide dates at some point, not necessary out of the gate for
this release. If we are not going to provide dates, then it should be
alphabetic.

On Tue, Nov 8, 2016 at 8:40 AM, Michael Kleinhenz notifications@github.com
wrote:

@Essjaysee https://github.com/Essjaysee on the sorting of iterations:
interesting problem, I don't have a solution for that yet. But thats also
not part of this story. Currently, new iterations are just appearing in
dropdowns on different views once created.

But this might be missing from #410
#410, because in order
to change the metadata of an iteration, the user has to select it somehow.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#409 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARTwqzf_Pphys_5YY3Vmr9fkOgcF9vkhks5q8HuygaJpZM4Kid1Y
.

[Essjaysee]

@michaelkleinhenz Thanks for your replies. Actually, I do need to figure out the ordering of the iteration for this story, because after a new iteration is created, I need to specify where to show it within the list. Details, details! :)

@Mgranfie Alphabetical seemed the most sensible to me too. My understanding was that dates would always be optional, so how we decide to order those without dates is always going to be relevant.

[Mgranfie]

+1 SJ

On Tue, Nov 8, 2016 at 9:46 AM, Sarahjane Clark notifications@github.com
wrote:

@michaelkleinhenz https://github.com/michaelkleinhenz Thanks for your
replies. Actually, I do need to figure out the ordering of the iteration
for this story, because after a new iteration is created, I need to specify
where to show it within the list. Details, details! :)

@Mgranfie https://github.com/Mgranfie Alphabetical seemed the most
sensible to me too. My understanding was that dates would always be
optional, so how we decide to order those without dates is always going to
be relevant.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#409 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARTwq0WKzG7bMXpAI9Xm4986IJFIl1Heks5q8ItRgaJpZM4Kid1Y
.

[michaelkleinhenz]

@Essjaysee details is why we are here :-)
We could do alphabetical, but as we will be having a "proper" ordering at some point, we might create throwaway code if we implement alphabetical now just to replace it later. For the work item list for example, we simply did not specify the order and left it be "undefined" resulting that the order was determined by the items order in the database.
What about only defining where new items show up (like "top of list" or "bottom of list") and not define a specific order?

[maxandersen]

If date is optional, the user would need to specify when creating the iteration that it is to be 'current' or 'future', right?

Yes. Look at jira and VSO they both does this afics.

Does an iteration only become 'past' once it is closed?

Yes.

How do we imagine the list of future iterations being ordered without dates? Another field where >you'd indicate its order in the list? Drag and drop on the iteration list? Simply the order of creation >without an option to reorder them?

Just reordering yes - see jira and VSO. All have ways for that.

github provides multiple ways to do ordering of iterations

I'm guessing we will allow for multiple current iterations?

Yes, but I expect a Team will only have one active iteration.

If we are not going to provide dates, then it should be
alphabetic.

I don't follow that. The iterations will be ordered, why not use that order by default ? Alphabetic means very little if anything at all for iterations/sprints.

[maxandersen]

What about only defining where new items show up (like "top of list" or "bottom of list") and not define a specific order?

Why not just have an order from day one ?

[michaelkleinhenz]

We can do that. Also see #410 (comment) for Todds comment on this issue. Looks like the create date should be the order.

[Essjaysee]

@joshuawilson @aslakknutsen @maxandersen @michaelkleinhenz Wireframes for iterations: https://redhat.invisionapp.com/share/KA9CAYL7M

[qodfathr]

Thanks, @Essjaysee . A few comments:

1. The two most important aspects of an iteration are the name and the (optional) dates. The first create dialog box should have those two elements. (i.e.., if you are trying to keep the dialog to 2 elements, Dates are far more important than Description.)
2. Once an iteration has been set with dates (e.g., a 2 week sprint), that 'model' can be used to default the next sprint. (e.g., if I create a sprint Jan 1-Jan 14, the next sprint can default to Jan 15-Jan 28)
3. Iteration names do not need to be unique. In fact, it's very important that duplicate names are permitted.

[michaelkleinhenz]

This issue was moved to fabric8-ui/fabric8-planner#646