Close an Iteration #411
Comments
|
@michaelkleinhenz and sarahjane I am wondering about the statement of closed iterations return to the backlog? I have a design for Past Iterations that will house closed iterations. Is there a call for cancelled iterations? Is this what you are referring to here to move back to the backlog?... thx. |
|
@Mgranfie work items that are open when closing an iteration would be moved to the backlog. But that is one of the areas that are very important but also very volatile. I can think of many usable behaviours for this, even specific for a certain process. This stuff may be defined by the WILTs in the future (or some other user-configurable process) because this may be needed differently on different projects/teams/customers. For now, we should assume something that makes sense. From the behaviour that GitHub uses, only one iteration can be set for a work item. In turn, that means we have to think about what to do with work items that are still in state "open" when an iteration is closed. In any usecase I can think of, the work items will then need to be "moved" out of the closed iteration. As we can not assume what the next iteration will be or if a work item will be in there, it's best to move them back to the backlog for new assignment to a new iteration. That was the reasoning about that behaviour. :-) |
|
@qodfathr ^^ |
|
@michaelkleinhenz should the move to backlog be an optional thing ? afaik it is in both jira and github, i.e. I can put an issue on closed iterations. |
|
@maxandersen I think it should not only an optional thing, but the whole behaviour should be configurable at some point. For now, I think we should assume something simple to start with. |
|
@michaelkleinhenz "it should not only an optional" - wdym ? that it should or should not be optional ? And yes, I agree to keep it simply first - just wanted to clarify that just because in the "close workflow" we move all open issues off you can still have closed iterations with open issues if you are such inclined. btw. what does "back to the backlog" mean - so far we have no definition of what backlog "is". |
|
I agree with moving to the backlog, it is fairly typical behavior. On This would prevent me from having to remember, find and then move any On Fri, Oct 28, 2016 at 4:32 AM, Max Rydahl Andersen <
|
|
Having been involved with implementations around this for other systems, my feedback is this: There is no need to have functionality w.r.t. closing an iteration. tl;dr: the real-world desire of users is to have powerful, manual capabilities at the end of a sprint and not automation of business rules. Essentially, users just want full flexibility to do whatever makes sense for them, and any automation around closing out iterations tends to cause more pain than satisfaction in the long run. In contrived, closed demonstration scenarios, sure, it can demo well as a feature. But in the real world, it's almost always the case that there are exceptions to the rule on every iteration. If an iteration has dates, then those dates can be used to drive the UI -- e.g., there can be an automatic understanding for the 'current iteration', simply based upon the date. But, beyond that, I'd caution against anything happening automatically. What's perhaps more important is the ability to filter and do bulk updates. For example, in a sprint retrospective at the end of a sprint, or perhaps as part of sprint planning at the start of the next iteration, the team likely will want to see just the stuff that was forecasted but did not get done. And, for the vast majority of these, they'll probably want to do the same operation. (e.g., we didn't complete items A, B C and D. We've agreed with the PO to move A, C and D into the next sprint.) So filtering + bulk select + some-operation would be a common scenario. (in this case, filter to undone, bulk-select all but B, move selection to next iteration). It's not a concern that people will forget to do these things -- there will be many other ways the team as visibility into the fact that stuff is in an "inappropriate" state. |
|
I agree Todd. The one thing I see is carrying forward and if you have not On Fri, Oct 28, 2016 at 1:45 PM, Todd Mancini notifications@github.com
|
|
I agree with @qodfathr about the closing of an iteration should not alter WIs data (including the association with a specific iteration). If it is possible to have a flexible filtered view of all "open" work items and a simple bulk update feature, that would be way better than forcing some automatism on users. I removed the requirement. @maxandersen I meant it should be configurable, but maybe way beyond a simple switch but with a configurable behavior (like "I want to have them removed from the sprint and add a tag "carried-over"). |
|
@maxandersen good point. I would suggest/think that "backlog" was the general term of referring to all work items not in an iteration for the current context. I added a note above. |
|
+1 for Todd's input - any rules that we impose at the end of an iteration would require giving users the ability to get around them. ;-) |
|
@michaelkleinhenz we need to be cautious how we think about a backlog -- because it can be different for different people/roles. At the end of the day, it's just a priority ordered list of stuff yet to be done. A developer may have the view that the backlog is the stuff that's not yet in a sprint, but a product manager would not make any such distinction -- to a product manager, either something is undone (in the backlog) or done (not in the backlog). While the work-in-progress is definitely important, it in no way changes the product manager's view of the backlog (undone vs done). |
|
Agree with Todd. Also, if we are going to allow users to plan ahead, we On Wed, Nov 2, 2016 at 8:49 AM, Todd Mancini notifications@github.com
|
|
Of course we should have a general bulk update feature eventually but absent of that then I would consider it critical we at least offer at close of sprint to move the issues to the next sprint (or back in backlog). Otherwise the detailed micro management of issues will kill usage immediately. And yes, backlog is more an implicit concept than a "thing" which is why "putting back on backlog" can be very ambiguous. |
|
case in point - in both github and jira if on close milestone or sprint I wouldn't offer to move issues over I could not see me use neither system at all for tracking sprints. Github don't have bulk updates and in jira they exist but require multiple steps/click and the least I would like to be burden with at end of sprint. |
|
and to be clear this should of course be optional to do - but we must provide some basic help to avoid users drowning in pushing data around. |
|
@maxandersen that convenience function is exactly what I had in mind when I wrote "moved back to backlog". That as a "yet-but-not-later default behaviour" would provide that convenience I think - and without introducing a button somewhere that we have to remove again later.
That would provide a system without the micromanagement of moving every leftover WI manually around from different places after an iteration. |
|
@qodfathr yes, I agree. That is the reason why I don't see any "fixed" lists later but merely "a list view with an applied filter". So a "backlog link" would just open a list of WIs with a pre-defined filter applied. If an iteration is opened, again, the WI list is opened with a predefined filter expression. That would be fully flexible to customized views, quick introduction of new features (like just add a menu point with a predefined filter expression applied) and this would even be easier to implement (at least in the UI). A drawback would be that the storing a user ordering then gets more complicated: the user re-orders his backlog (which is only a filtered list). How is the ordering stored? How is the ordering stored if the user creates custom lists using custom filter expressions? We can solve that, but it needs some thoughts on that all. And that is the reason filtering/searching is an epic :-) |
|
@michaelkleinhenz are you suggesting that there are per-user orderings of a backlog? Because I do not see that as a requirement (or even a 'good thing' :) ) Being able to rearrange the stack ordering should be a privileged operation. [e.g. anyone can add to the end of the backlog, but only the PO can rearrange the backlog.] There are some well established algorithms for dealing with this problem, even when lists are filtered. You end with up some crazy numerical values on the actual stack rankings, but these are generally hidden in the UX. (e.g. a stack ranking of 5 items may end up being {10000; 21221.333; 784432.973; 784932.12; 3254731.7592} I'd just have the stack rank be a single numerical value on each work item, and you generally display a set of work items with ORDER BY stack_rank |
|
@qodfathr when you say "add to the end of the backlog" you mean in a perfect world that new items are added with the lowest business or more generic "Product owner team" (POT) priority - or maybe even more precisely, has no ordering at all since noone not even looked at it. (stack_rank: MAX_BIGINT) Question is - should this ordering really be truly global ? would it not be more useful to have an explicit backlog construct (i.e. a special iteration) where in the ordering is explicitly managed rather than global ? I know I've in past been fan of "global ordered" stack_rank but the more i think about the real world works differently. When two teams work together and maybe share some work items their independent product owners priority will not necessarily be the same. thoughts ? |
|
@qodfathr no, I did not mean that :) Sure, there must be authZ in place that controls who can re-order items in lists (including the backlog). But consider the following: there is a backlog that is defined as a partial of the whole of WIs by some kind of criteria (like all WIs that are in a project not assigned with an iteration). And then there might be something like a "personal worklist", all WIs that are assigned to me (the user). On this list, the user should be able to re-order the items to match his personal priority. And that order should be independent from other orderings. If the PO reorders WIs in the iteration list, this should not touch a personal worklist of a user. We basically have two different topics here, that we should not mix up:
My thinking about this: on 1: I think the filter expression way is way more flexible. on 2: ordering should be attached to the list, not the WI. |
|
One addition: Jira uses something like a mixture of fixed lists and user-defined lists based on filter expressions. Thats fine as long as in the implementation all lists are using the same tech, like "the fixed lists are just non-modifyable filter expressions internally". |
|
@michaelkleinhenz I actually believe jira has global ordering. If you move an item on one list it moves on another. Its definition for boards though is a query though and then it maps that out over sprints (what we call iterations) and anything that is not on an iteration is put onto what Jira calls a backlog. The last part (board defined by query) is really powerful and I believe we need the same in the long run. But I'm getting more and more convinced global backlog ordering as a single field on WorkItem is a Bad Thing. It makes much more sense for me that each person/team/board can have their own ordering - since as you say individually I got another order to simply execute on the issue. I spent some time with VSO over the weekend and they do this too - backlog order is by team/board. About wether ordering shuold be attached to the List or WI then I agree - it is not the WI, it is the list but you might want to go one level further and say the ordering is something that is associated with the entity (which could be a person or team) and possibly you would want to be able to say two teams share the same backlog ordering in case they have the same Business owner. |
|
I feel we are getting very close to the point whereby we'll have to agree to disagree, and move on. I see lots of arguments based upon interesting EDGE use cases, without addressing the PRIMARY use case. A PO defines the universal, global stack ranking of the backlog. Period. That's how teams work. What I'm failing to see in the counter examples is this: when a PO reorders the backlog, if that's a 'per user' ordering, then how does the rest of the team know what priority to work on stuff? There HAS to be the one, definitive global ordering -- anyone who uses backlogs will all but demand this. Let's consider 'per user' orderings as a 2ndary feature, and something that we somehow rationalize against the global ordering. And let's make sure we've got scenarios and value props to back this new feature. But, for now, let's just do a global ordering. |
|
While the discussion about local and global backlogs is interesting, I fail to see how it pertains to the implementation of this story. I think there is agreement that closing a sprint does not affect the order of execution of the work items. |
|
@qodfathr you do realize VSO does not have global ordering, right - it has per board/team (not sure which it is because they are ambigious about it in their docs/ui) ? Are you by global ordering really intending it to be fully global ordering across all projects, teams, and organizations ? Per user is just a sideeffect that gets possible by having non-global ordering. |
|
@tsmaeder agreed - this discussion is really for about backlog management rather than iterations. |
|
@maxandersen @tsmaeder Agreed. @qodfathr I think making the order local to a list (like "backlog", "iteration x" or something else) solves that problem. If the PO makes a change to the ordering in the backlog, all users can see that change while it does not affect other orderings in other lists. |
|
@michaelkleinhenz but there really are no 'other lists'. These other lists you speak of are simply different views on the same list, filtered by particular criteria, either showing or not showing parent/child nodes, and ordered by some column of data. 'Priority' is simply one of the numerical data fields of a work item, and it is generally the default sort order for all views. I am going to use executive power to end this conversation. The specification for v1 is set, and we need to move on. If anyone wants to revisit this post-v1, feel free to bring it as a proposal to the product planning meeting in January. |
|
@qodfathr did you see my question ? Are you saying you want global priority across all org, teams, boards etc. even though we only know of one other system that does this (jira) and it seem to be more pain than good to use ? |
|
and to be clear, in a "i'm ordering" the backlog scenario there is no ordered by some column of data it is the priority as otherwise moving issues up and down start meaning something else. Likewise with Quick Add, the requirement is "add to end of backlog", if that is to be done by some other means than a specific ordered field we need to do something alot more generic than we are currently discussing here. |
|
btw. I found an article that says the internals on VSO does it on a field (https://blogs.msdn.microsoft.com/visualstudioalm/2014/05/14/behind-the-scenes-the-backlog-priority-or-stack-rank-field/ and https://blogs.msdn.microsoft.com/visualstudioalm/2014/07/08/where-is-the-field-on-the-work-item-form-to-order-the-backlog/). As far as I can see it VSO did this because of the technical debt they had by having priority/stack-rank on the work item rather than having it separated out. Same issue exist in Jira. It means that if two teams have the same item on their backlog they will be affecting their different teams execution order/priorities. |
|
@qodfathr I reread your comments again and you seem to focus on the mention of the ability of per user backlogs, that is really not the point we are pushing for - it is for per team or per group of teams backlog order we are talking about. |
|
@maxandersen but we DO have per-team backlogs, inasmuchas a team's UX (1) filters to certain areas and (2) can have its own iterations. 1 project backlog + filtering gets the job done. We can discuss alternatives for our next season of development in January. I look forward to playing around with the implementation of the current PDD very soon. |
|
When the current iteration is closed, does the first item in the list of 'future' iterations become current? Do we want the user to do a separate action to select which iteration should now be considered 'current'? |
When the iterations are in a sequence then there should always be a "current" IMO. |
|
@Essjaysee talked about that with Pete, there is no automatic actions on closing an iterations at all. So if there are "current" or "active" iterations, the user has to manually make them be an active iteration. @maxandersen agreed, but the start and end dates are optional on iterations, so we can not rely on a date sequence. On the order of iterations: let's move that discussion on the order of the list of iterations over to #409, where we already talk about that. |
|
@michaelkleinhenz so what we are saying here is that the dates on iterations are more like meta data and do not automate anything. The users will manually kick off and close an iteration, as we do in JIRA today. This means that there could be a case where until you kick off an iteration, there is no iteration in "Current"? @Essjaysee |
|
@joshuawilson @aslakknutsen @maxandersen @michaelkleinhenz Wireframes for iterations: https://redhat.invisionapp.com/share/KA9CAYL7M |
Description
As a user, I want to close an iteration. Closing an iteration means the iteration has been completed.
Functional Acceptance Criteria
Note: work items in the state "open" (or semantically equivalent) that are contained/associated with an iteration at the time the iteration is closed are still associated with the iteration. They must be moved manually from one iteration to another. This is because in the final system, there will be a filtered global view with all work items regardless of iteration association where the user can pick and mass update work items for moving to a different (following) iteration.
Note: the "backlog" is considered the ordered (by order-of-execution) list of all work items of the context not in an iteration.
Non-functional Acceptance Criteria
Dependencies
The text was updated successfully, but these errors were encountered: