Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save martinobettucci/ca423c6aa243300114c651dac2c96eee to your computer and use it in GitHub Desktop.
Save martinobettucci/ca423c6aa243300114c651dac2c96eee to your computer and use it in GitHub Desktop.
This is a rolling-by (updated as soon as I think an improvement can be done) rule-of-thumbs I suggest to read and possibly print to remember everyone we are a team and we share our responsibilities.

THE TAO OF THE AGILE SOFTWARE CONTRIBUTOR

  • I look into my dashboard to see what's pending from my team between each resolved issue.
  • I should be aware that issues pending feedback are not only standing-by tickets but people and I assure them all my efforts to let them move forward.
  • I should take my next ticket from the current sprint pool and from the out of sprint pool in this order.
  • Priority should be my best concern, I should take tasks based on their priority from critical, major, medium, minor and trivial in this order.
  • Blocker priority should be taken instantly regardless of their positioning.
  • As soon as I decide to be in charge of an issue, I should assign that to me as to notify my peers that I will handle and take care of that.
  • As soon as I take an issue in charge, I will plan a discussion with the reporter to share knowledge and our point of views.
  • When I finally start my meeting or my developments, I put the issue in DEVELOPMENT as to notify my line managers I started looking/working on it.
  • About a task or a story, I should add a comment as soon as I read the associated story and the associated spec: this can be "I've read it, all clear" or "I've read it, need to speak with @someone about topic".
  • About a bug, I should add a comment as soon as I can reproduce the issue to notify my line manager that resolution investigation have started.
  • At the end of the day, if a I have issues I'm in charge whose are still pending, I should add a comment about my current findings: it doesn't matter if I will be found wrong later, I have to tell others my current progress as to notify my peers about what I have done so far; this can be "I just started looking around, I have not reproduced" or "I think but I'm not sure it may concern ..." or anything but not leaving the issue commentless.
  • During my progress, I should have a look into the referenced stories and specifications as well as the test books to give my advices and point of view: I should contribute to them using of my technical skills and knowledge of the product I'm changing and be responsible about the consequences of my work.
  • As soon as I resolved the issue, I should add a comment saying briefly what I've done and how I resolved the issue for history purpose.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment