On 2 fév, 14:46, Martin Häcker <[email protected]> wrote: > Hi Jerome, > > Am 31.01.11 11:31, schrieb jmb: > >> 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). > > This looks like your PO is indeed working as a team member in the scrum > team which is great. > > I would suggest that you do not accept stories directly (neither the PO > nor individual developers) but instead just change the status of the > story and use tasks for all of the tasks included. This would mean: > > - Two tasks in the beginning: 'Write Documentation' and 'Review > Documentation' > - One Team member writes the docs, and then asks another (the PO in this > case?) to start the second task 'review'. (Maybe this doesn't need to be > to all eternity? Your Work agreement could maybe just specify a 4 eyes > principle for documentation?) I am not sure what you mean by that. Once the PO has proof read a document and agrees with the contents, he simply closes the story.
On re-reading what I wrote above, there might be a misunderstanding on the word “accept”. I meant it in the Trac sense of checking the “accept” radio button, not in the Scrum sense of “accepting the story as done”. Is that where your question comes from? > - When the review brings up points to work on, they are either just > corrected or another task is created for that story to correct those > issues and maybe another review task if required. > - When the sprint ends or the story is done (either way works fine) the > story is presented to the PO and accepted / rejected > > On second thought: You may have an opportunity for improvement by > pulling in writing the documentation in the feature story that creates > the story. > Thanks for your reply. This is not a very big issue anyway since the PO can reassign the stories through the ticket edit interface instead of the backlog. 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
