0

I have inherited a process where gerrit is used to capture and collaborate on user stories.

The process is used at the very early stage of capturing the stories and it seems very long winded compared to a whiteboard approach.

It feels like this process goes against the spirit of user stories where collaboration and face to face discussions seem to be favored.

Also, gerrit tooling is aimed more around the technical user. Knowledge of git is required to edit stories which seems to push writing the stories onto the technical team.

Question: Is it possible to effectively capture and collaborate on stories using gerrit? If so, how can this be done?

Chris Snow
  • 23,813
  • 35
  • 144
  • 309
  • capture stories from where? what do you mean on editing stories? – laplasz Oct 29 '13 at 22:41
  • Stories are captured mostly from unstructured email 'conversations' with the stakeholders. One person will try to extract the stories from the emails. The stories are committed to git, and published for review using gerrit. Stakeholders then use gerrit's commenting system to provide feedback on whether the author of the stories has understood the requirements correctly. The stories will be edited by the original author based on the comments and then re-submitted using git patches. This offline cycle may repeat a number of times. – Chris Snow Oct 30 '13 at 01:31
  • which task repository do you use to track the stories? or I guess this is what is missing now, since you mentioning emails instead of bugzilla, jira, tuleap – laplasz Oct 30 '13 at 08:58
  • The stories are just committed as text files into git. There isn't any other task repository. – Chris Snow Oct 30 '13 at 09:02

1 Answers1

1

I think that is a problem - every story should have an Id. And using a task repository you can collaborate on stories very easily with the customers. Gerrit is a review tool not an issue tracker. The commit message should contain the issue Id. if you using Tuleap as an issue tracker then it is integrated with Gerrit. So if the commit msg contains issue id, then customer can click on the id and will be navigated to the issue/story

laplasz
  • 3,359
  • 1
  • 29
  • 40
  • Should every scenario within the story have an ID too? Or is that too low level? – Chris Snow Oct 30 '13 at 09:54
  • 1
    Stories can/should have subtasks. Each subtask has an Id. So in this case the story is a container/parent of subtasks/children tasks. A commit should contain changes of the given subtask. So yes it is a good practise to subtask a story – laplasz Oct 30 '13 at 12:21