On 31 jan, 10:14, Martin Häcker <[email protected]> wrote: > Hi Jerome, > > Am 31.01.11 09:52, schrieb jmb: > > > I just noticed that editing a ticket in the backlog view may bypass > > the normal ticket workflow. This happened when reassigning a ticket to > > someone else: when this is done through the ticket edit view, changing > > the owner of a ticket will cause that ticket to go back to "new" > > state. When it is done through the backlog, the ticket remains in > > whatever state it was (often "assigned"). > > > Is there a way to either disable owner changes from the backlog or > > make it follow the normal ticket workflow? Note that I still want to > > be able to edit other ticket fields through the backlog (summary, > > sprint and remaining time). > > Sadly thats quite hard, as trac does not expose a real API for that. We > try to invoke the workflows wherever we can, but since we can only use a > heuristic for this, it will sometimes fail. > > Our suggested workflow for this is that stories are not assigned to > individuals (as the team commits to them in the sprint planning meeting > and then solves them together). Instead they are broken down in tasks > and those are accepted by the individual that starts doing them himself. > > This workflow has worked quite well for other customers - if it doesn't > work for you, could you please present the usecases you are trying to > solve so we can evaluate if we need to support them or can propose you > other options to realize them. > Most of our stories are indeed not assigned to individuals (well, actually they are assigned to the PO since ISTR that I was unable to leave them unassigned when they were written, but their assignment does not change). However, we have some stories that concern writing user documentation. Those stories get planned for a sprint whereupon they get broken down into tasks (usually a single task) and the documentation is written. At that point, the story is assigned to the PO so that he can proof-read the document. If there are modifications to do, the story is re-assigned to whomever wrote the document for correction (which may result in a new task for the next sprint backlog or be tracked through a contingent). We noticed the issue because the PO had accepted such a story, found that the document needed some corrections and re-assigned the story through the backlog. Now it looks like the developer has accepted the story although in fact he has not (yet).
Jerome -- Follow Agilo on Twitter: http://twitter.com/agiloforscrum Please support us by reviewing and voting on: http://userstories.com/products/8-agilo-for-scrum http://ohloh.net/p/agilo-scrum http://freshmeat.net/projects/agiloforscrum You have received this message because you are subscribed to the "Agilo for Scrum" Google Group. This group is focused on supporting Agilo for Scrum users and is moderated by Agilo Software GmbH <http://www.agiloforscrum.com>. To post to this group, send email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/agilo
